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About This Book 


This book contains reference information on: 

* Using preprocessor statements in your program. 
* Macros defined by the ILE C/C++ compiler. 

* Pragmas recognized by the ILE C/C++ compiler 


* Command lines options for both native iSeries and QShell working 
environments. 


¢ I/O considerations for the iSeries environment. 


Who Should Use This Guide 


This guide is for programmers who are familiar with the C and C++ programming 
languages and who plan to use the ILE C/C++ compiler to build new or maintain 
existing ILE C/C++ applications. You need experience in using applicable iSeries 
menus and displays or Control Language (CL) commands. You also need 
knowledge of ILE as explained in the ILE Concepts manual. 


Prerequisite and Related Information 


Use the iSeries Information Center as your starting point for looking up iSeries and 
AS/400 Advanced Series technical information. You can access the Information 
Center in two ways: 
* From the following Web site: 

http://www. ibm.com/eserver/iseries/infocenter 
* From CD-ROMs that ship with your Operating System/400 order: 

iSeries Information Center, SK3T-4091-00. This package also includes the PDF 


versions of iSeries manuals, iSeries Information Center: Supplemental Manuals, 
SK3T-4092-00, which replaces the Softcopy Library CD-ROM. 


The iSeries Information Center contains advisors and important topics such as CL 
commands, system application programming interfaces (APIs), logical partitions, 
clustering, Java” , TCP/IP, Web serving, and secured networks. It also includes 
links to related IBM® Redbooks and Internet links to other IBM Web sites such as 
the Technical Studio and the IBM home page. 


Other information is listed in the |“Bibliography” on page 127 


Install Licensed Program Information 


On systems that will be making use of the ILE C/C++ compiler, the QSYSINC 
library must be installed. 


A Note About Examples 


Examples illustrating the use of the ILE C/C++ compiler are written in a simple 
style. The examples do not demonstrate all of the possible uses of C or C++ 
language constructs. Some examples are only code fragments and do not compile 
without additional code. 
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Control Language Commands 


If you need prompting, type the CL command and press F4 (Prompt). If you need 
online help information, press F1 (Help) on the CL command prompt display. CL 
commands can be used in either batch or interactive mode, or from a CL program. 


For more information about CL commands, see the CL and APIs section in the 
Programming category at the iSeries 400 Information Center Web site: 


http://publib. boulder. ibm.com/pubs/html/as400/infocenter.htm 


You need object authority to use CL commands. For more information on object 
authority, see the Basic System Security and Planning section in the System 
Administration, Availability, and Maintenance category at the Information Center Web 
site. 


How to Read the Syntax Diagrams 


vi 


* Read the syntax diagrams from left to right, from top to bottom, following the 
path of the line. 


The »>—— symbol indicates the beginning of a command, directive, or statement. 


The —» symbol indicates that the command, directive, or statement syntax is 
continued on the next line. 


The »— symbol indicates that a command, directive, or statement is continued 
from the previous line. 


The —»< symbol indicates the end of a command, directive, or statement. 


Diagrams of syntactical units other than complete commands, directives, or 
statements start with the »— symbol and end with the —» symbol. 


Note: In the following diagrams, statement represents a C or C++ command, 
directive, or statement. 


* Required items appear on the horizontal line (the main path). 


>>—statement—required_item >< 


* Optional items appear below the main path. 


>>—statement >< 
Lapeienat 4 toi! 


* If you can choose from two or more items, they appear vertically, in a stack. 


If you must choose one of the items, one item of the stack appears on the main 
path. 


em Taree pe eee >< 
requi redrohoiees | 


If choosing one of the items is optional, the entire stack appears below the main 
path. 


optional_choicel— 


>>—statement E >< 
optional_choice2— 


The item that is the default appears above the main path. 
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--default_item—— 
>>—statement——alternate_item >< 


* An arrow returning to the left above the main line indicates an item that can be 
repeated. 


v 


>>—statement repeatable_item >< 


A repeat arrow above a stack indicates that you can make more than one choice 
from the stacked items, or repeat a single choice. 
* Keywords appear in nonitalic letters and should be entered exactly as shown 
(for example, extern). 
Variables appear in italicized lowercase letters (for example, identifier). They 
represent user-supplied names or values. 
* If punctuation marks, parentheses, arithmetic operators, or other such symbols 
are shown, you must enter them as part of the syntax. 
The following syntax diagram example shows the syntax for the #pragma 
comment directive. See |“Pragma Directives (#pragma)” on page 16}for information 
on the #pragma directive. 


HHH G 5 6 ob 


>>—#—pragma—comment—( compiler )-»<« 
date 
timestamp 
copyright 
user | | »—'characters"— 
8 | 


This is the start of the syntax diagram. 

A The symbol # must appear first. 

The keyword pragma must appear following the # symbol. 

[4 The keyword comment must appear following the keyword pragma. 

f An opening parenthesis must be present. 

[4 The comment type must be entered only as one of the types indicated: 
compiler, date, timestamp, copyright, or user. 

A comma must appear between the comment type copyright or user, and 
an optional character string. 

EJ A character string must follow the comma. The character string must be 
enclosed in double quotation marks. 

E] A closing parenthesis is required. 

This is the end of the syntax diagram. 


The following examples of the #pragma comment directive are syntactically correct 
according to the diagram shown above: 


#pragma comment (date) 
#pragma comment (user) 
#pragma comment(copyright,"This text will appear in the module") 
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How to Send Your Comments 


Your feedback is important in helping to provide the most accurate and 
high-quality information. IBM welcomes any comments about this book or any 
other iSeries documentation. 
* If you prefer to send comments by mail, use the following address: 

IBM Canada Ltd. Laboratory 

Information Development 

2G/KB7/1150/TOR 


1150 Eglinton Avenue East 
Toronto, Ontario, Canada M3C 1H7 


If you are mailing a readers’ comment form from a country other than the 
United States, you can give the form to the local IBM branch office or IBM 
representative for postage-paid mailing. 


* If you prefer to send comments electronically, use one of these e-mail addresses: 
— Comments on books: 
torrcf@ca.ibm.com 
— Comments on the iSeries 400 Information Center: 
RCHINFOC@us.ibm.com 


Be sure to include the following: 

¢ The name of the book 

* The publication number of the book 

* The page number or topic to which your comment applies. 
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Chapter 1. Preprocessor Directives 


This chapter describes the C/C++ preprocessor directives. 


Preprocessor Overview 


Preprocessing is a preliminary operation on C and C++ files before they are passed 
to the compiler. Preprocessing lets you: 


Replace tokens in the current file with specified replacement tokens 
Imbed files within the current file 

Conditionally compile sections of the current file 

Generate diagnostic messages 


Change the line number of the next line of source and change the file name of 
the current file 


Apply machine-specific rules to specified sections of code 


A token is a series of characters delimited by white space. The only white space 
allowed on a preprocessor directive is the space, horizontal tab, vertical tab, form 
feed, and comments. The new-line character can also separate preprocessor tokens. 


The preprocessed source program file must be a valid C or C++ program. 


The preprocessor is controlled by the following directives: 


#define Defines a preprocessor macro. 

#undef Removes a preprocessor macro definition. 

#error Defines text for a compile-time error message. 

#include Inserts text from another source file. 

#if Conditionally suppresses portions of source code, depending on 
the result of a constant expression. 

#ifdef Conditionally includes source text if a macro name is defined. 

#ifndef Conditionally includes source text if a macro name is not defined. 

#else Conditionally includes source text if the previous #if, #ifdef, 
#ifndef, or #elif test fails. 

#elif Conditionally includes source text if the previous #if, #ifdef, 
#ifndef, or #elif test fails, depending on the value of a constant 
expression. 

#endif Ends conditional text. 

#line Supplies a line number for compiler messages. 

#pragma Specifies implementation-defined instructions to the compiler. 
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Preprocessor Directive Format 


Preprocessor directives begin with the # token followed by a preprocessor 
keyword. The # token must appear as the first character that is not white space on 
a line. The # is not part of the directive name and can be separated from the name 
with white spaces. 


A preprocessor directive ends at the new-line character unless the last character of 
the line is the \ (backslash) character. If the \ character appears as the last 
character in the preprocessor line, the preprocessor interprets the \ and the 
new-line character as a continuation marker. The preprocessor deletes the \ (and 
the following new-line character) and splices the physical source lines into 
continuous logical lines. 


Except for some #pragma directives, preprocessor directives can appear anywhere 
in a program. 


Macro Directives and Operators (#define, #undef, #, ##) 


2 


A macro is a literal name that can be assigned a value. Before a program is 
compiled, the preprocessor substitutes occurences of each macro in program source 
code with that macro’s assigned value. 


Macros can be predefined by the operating system or the compiler. See |Chapter 2, 
“Predefined Macros” on page 17| for more information on these. 


Macros can also be defined in program source code, as described below. 


#define (Defining and Expanding a Macro) 


The preprocessor define directive directs the preprocessor to replace all subsequent 
occurrences of a macro with specified replacement tokens. 


The define directive has the form: 


p>>—i#—_define—identifier—,~—— ee oo 


(— ) | identifier— 
daent Hier “character— 


The define directive can contain an object-like definition or a function-like 
definition. 


Object-Like Macros 

An object-like macro definition replaces a single identifier with the specified 
replacement tokens. The following object-like definition causes the preprocessor to 
replace all subsequent instances of the identifier COUNT with the constant 1000: 


#define COUNT 1000 


If the statement 
int arry[COUNT] ; 


appears after this definition and in the same file as the definition, the preprocessor 
would change the statement to 
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int arry[1000]; 
in the output of the preprocessor. 


Other definitions can make reference to the identifier COUNT: 
#define MAX_COUNT COUNT + 100 


The preprocessor replaces each subsequent occurrence of MAX_COUNT with 
COUNT + 100, which the preprocessor then replaces with 1000 + 100. 


If a number that is partially built by a macro expansion is produced, the 
preprocessor does not consider the result to be a single value. For example, the 
following will not result in the value 10.2 but in a syntax error. 


#define a 10 
a.2 


Using the following also results in a syntax error: 


#define a 10 
#define b a.11 


Identifiers that are partially built from a macro expansion may not be produced. 
Therefore, the following example contains two identifiers and results in a syntax 
error: 


#define d efg 
abcd 


Function-Like Macros 
A function-like macro definition replaces a single identifier with the result of a 
specified function. 


Defining: 
An identifier is followed by a parenthesized parameter list and the 
replacement tokens. The parameters are imbedded in the replacement code. 
White space cannot separate the identifier (which is the name of the 
macro) and the left parenthesis of the parameter list. A comma must 
separate each parameter. For portability, you should not have more than 31 
parameters for a macro. 


Invoking: 
An identifier is followed by a list of arguments in parentheses. A comma 
must separate each argument. Once the preprocessor identifies a 
function-like macro invocation, argument substitution takes place. A 
parameter in the replacement code is replaced by the corresponding 
argument. Any macro invocations contained in the argument itself are 
completely replaced before the argument replaces its corresponding 
parameter in the replacement code. 


The following line defines the macro SUM as having two parameters a and b and 
the replacement tokens (a + b): 


#define SUM(a,b) (a + b) 


This definition would cause the preprocessor to change the following statements (if 
the statements appear after the previous definition): 


SUM(x,y) 3 
d * SUM(x,y)3 


c 
c 


In the output of the preprocessor, these statements would appear as: 
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(x + y)s 
d * (x + y); 


c 
c 


Use parentheses to ensure correct evaluation of replacement text. For example, the 
definition: 
#define SQR(c) ((c) * (c)) 


requires parentheses around each parameter c in the definition in order to correctly 
evaluate an expression like: 


y = SQR(a + b); 


The preprocessor expands this statement to: 
y= ((a + b) * (a + b)); 


Without parentheses in the definition, the correct order of evaluation is not 
preserved, and the preprocessor output is: 


y=(a+b*a+b); 


Arguments of the # and ## operators are converted before replacement of 
parameters in a function-like macro. 


The number of arguments in a macro invocation must be the same as the number 
of parameters in the corresponding macro definition. 


Commas in the macro invocation argument list do not act as argument separators 
when they are: 


* in character constants 
* in string literals 
* surrounded by parentheses 


Once defined, a preprocessor identifier remains defined and in scope independent 
of the scoping rules of the language. The scope of a macro definition begins at the 
definition and does not end until a corresponding undef directive is encountered. 
If there is no corresponding undef directive, the scope of the macro definition lasts 
until the end of the compilation unit. 


A recursive macro is not fully expanded. For example, the definition 
#define x(a,b) x(atl,b+1) + 4 


expands 
x(20,10) 


to 
x(20+1,10+1) + 4 


rather than trying to expand the macro x over and over within itself. After the 
macro x is expanded, it is a call to function x(). 


A definition is not required to specify replacement tokens. The following definition 
removes all instances of the token debug from subsequent lines in the current file: 


#define debug 


You can change the definition of a defined identifier or macro with a second 
preprocessor define directive only if the second preprocessor define directive is 
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preceded by a preprocessor undef directive. The undef directive nullifies the first 
definition so that the same identifier can be used in a redefinition. 


Within the text of the program, the preprocessor does not scan character constants 
or string constants for macro invocations. 


Example: #define directive 


The following program contains two macro definitions and a macro invocation that 
refers to both of the defined macros: 
[** 


** This example illustrates #define directives. 
**/ 


#include <stdio.h> 


#define SQR(s) ((s) * (s)) 

#define PRNT(a,b) \ 
printf("value 1 
printf("value 2 


%d\n", a); \ 
%d\n", b) ; 


int main(void) 
{ 
int x 
int y 


23 
33 


PRNT(SQR(x) ,y)3 


return(0) ; 


} 


After being interpreted by the preprocessor, this program is replaced by code 
equivalent to the following: 


#include <stdio.h> 


int main(void) 
{ 
int x 
int y 


23 
33 


printf("value 1 
printf("value 2 


sd\n", ( (x) * (x) ) )s 
%d\n", y)s 


return(0); 


} 


The program produces the following output: 
4 
3 


#undef (Undefining a Macro) 


The preprocessor undef directive causes the preprocessor to end the scope of a 
preprocessor definition. 


value 1 
value 2 


The undef directive has the form: 
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>>—#—undef—identifier >< 


If the identifier is not currently defined as a macro, undef is ignored. 
Example: #undef directive 


The following directives define BUFFER and SQR: 


#define BUFFER 512 
#define SQR(x) ((x) * (x)) 


The following directives nullify these definitions: 


#undef BUFFER 
#undef SQR 


Any occurrences of the identifiers BUFFER and SQR that follow these undef 
directives are not replaced with any replacement tokens. Once the definition of a 
macro has been removed by an undef directive, the identifier can be used in a new 
define directive. 


# Operator 


The # (single number sign) operator converts a parameter of a function-like macro 
into a character string literal. 


For example, if macro ABC is defined using the following directive: 
#define ABC(x)  #x 


all subsequent invocations of the macro ABC would be expanded into a character 
string literal containing the argument passed to ABC. For example: 


Invocation Result of Macro Expansion 
ABC(1) "1" 
ABC(Hello there) "Hello there" 


The # operator should not be confused with the null directive. 


Use the # operator in a function-like macro definition according to the following 

rules: 

* A parameter following # operator in a function-like macro is converted into a 
character string literal containing the argument passed to the macro. 

* White-space characters that appear before or after the argument passed to the 
macro are deleted. 

* Multiple white-space characters imbedded within the argument passed to the 
macro are replaced by a single space character. 

* If the argument passed to the macro contains a string literal and if a \ 
(backslash) character appears within the literal, a second \ character is inserted 
before the original \ when the macro is expanded. 

* If the argument passed to the macro contains a " (double quotation mark) 
character, a \ character is inserted before the " when the macro is expanded. 

* The conversion of an argument into a string literal occurs before macro 
expansion on that argument. 
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* If more than one ## operator or # operator appears in the replacement list of a 
macro definition, the order of evaluation of the operators is not defined. 


* If the result of the macro expansion is not a valid character string literal, the 
behavior is undefined. 


Example: # operator 


The following examples demonstrate the use of the # operator: 


#define STR(x) #X 

#define XSTR(x) STR(x) 

#define ONE 1 
Invocation Result of Macro Expansion 
STR(\n oY i '\n') "\ hi AA" Nia! 
STR(ONE) "ONE" 
XSTR (ONE) mr 
XSTR("hello") "\"hello\"" 


## Operator (Macro Concatenation) 


The ## (double number sign) operator concatenates two tokens in a macro 
invocation (text and/or arguments) given in a macro definition. 


If a macro XY was defined using the following directive: 
#define XY(x,y) x##y 


the last token of the argument for x is concatenated with the first token of the 
argument for y. 


For example, 


Invocation Result of Macro Expansion 
XY(1, 2) 12 
XY(Green, house) Greenhouse 


Use the ## operator according to the following rules: 


* The ## operator cannot be the very first or very last item in the replacement list 
of a macro definition. 


* The last token of the item in front of the ## operator is concatenated with first 
token of the item following the ## operator. 


* Concatenation takes place before any macros in arguments are expanded. 


¢ If the result of a concatenation is a valid macro name, it is available for further 
replacement even if it appears in a context in which it would not normally be 
available. 


* If more than one ## operator and/or # operator appears in the replacement list 
of a macro definition, the order of evaluation of the operators is not defined. 


Example: ## operator 


The following examples demonstrate the use of the ## operator: 


#define ArgArg(x, y) x##y 
#define ArgText (x) X##TEXT 
#define TextArg(x) TEXT##X 


Chapter 1. Preprocessor Directives 7 


#define TextText TEXT##text 


#define Jitter 1 

#define bug 2 

#define Jitterbug 3 

Invocation Result of Macro Expansion 
ArgArg(lady, bug) ladybug 

ArgText (con) conTEXT 

TextArg (book) TEXTbook 

TextText TEXTtext 

ArgArg(Jitter, bug) 3 


Preprocessor Error Directive (#error) 


A preprocessor error directive causes the preprocessor to generate an error message 
and causes the compilation to fail. 


The error directive has the form: 


v 


>>—#—_error character. >< 


Use the error directive as a safety check during compilation. For example, if your 
program uses preprocessor conditional compilation directives, put error directives 
in the source file to prevent code generation if a section of the program is reached 
that should be bypassed. 


For example, the directive 
#error Error in TESTPGM1 - This section should not be compiled 


generates the following error message: 
Error in TESTPGM1 - This section should not be compiled 


File Inclusion (#include) 


A preprocessor include directive causes the preprocessor to replace the directive with 
the contents of the specified file. The include directive has the form: 


p>—#include——<fi lea >< 
i" filename" 


The following table indicates the search path compiler takes for source physical 
files. See the default file names and search paths below. 


Filename Member File Library 
mbr mbr default file default search 
file/mbr* mbr file default search 
mbr.file mbr file default search 
lib/file/mbr mbr file lib 
lib/file(mbr) mbr file lib 
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Filename Member File Library 


Note: 


1 Tf the include file format <file/mbr.h> is used, the compiler searches for mbr in the file in 
the library list first. If mbr is not found, then the compiler searches for mbr.h in the same 
file in the library list. Only "h” or "H” are allowed as member name extensions. 


The location of the source program file determines how include files are specified 

in the program source: 

* For a source program residing in an IFS system, all include files, whether 
IFS-based or physical file members, must be specified in IFS format. 

* For a source program that is a physical file member, only files that are also 
physical file members can be specified as include files. IFS files cannot be 
specified. 


If library and file are not specified, the preprocessor uses a specific search path 
depending on which delimiter surrounds the filename. The < > delimiter specifies 
the name as a system include file. The """ delimiter specifies the name as a user 
include file. 


The following describes the search paths for the #include directive used by the 
compiler. 
* Default File Names When the Library and File are not Named (member name 
only): 
Include Type Default File Name 
<> OCSRC 


wea The source file of the root source member, where root source 
member is the library, file, and member determined by the 
SRCFILE option of the Create Module or Create Bound Program 
commands. 


* Default Search Paths When the Filename is not Library Qualified: 
Include Type Search Path 
<> Searches the current library list (*LIBL) 


mee Checks the library containing the root source member; if not 
found there, the compiler searches the user portion of the library 
list, using either the filename specified or the file name of the 
root source member (if no filename is specified); if not found, 
the compiler searches the library list (*LIBL) using the specified 
filename. 


* Search Paths When the Filename is Library Qualified (lib/file/mbr): 
Include Type Search Path 
<> Searches for lib/file/mbr only 


nu Searches for the member in the library and file named. If not 
found, searches the user portion of the library list, using the file 
and member names specified. 


User includes are treated the same as system includes when the *SYSINCPATH 
option has been specified with the Create Module or Create Bound Program 


commands. 
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The preprocessor resolves macros on a #include directive. After macro 
replacement, the resulting token sequence must consist of a file name enclosed in 
either double quotation marks or the characters < and >. For example: 


#define MONTH <july.h> 
#include MONTH 


Usage 


If there are a number of declarations used by several files, you can place all these 
definitions in one file and #include that file in each file that uses the definitions. 
For example, the following file defs.h contains several definitions and an inclusion 
of an additional file of declarations: 


/* defs.h */ 

#define TRUE 1 

#define FALSE 0 
#define BUFFERSIZE 512 
#define MAX_ROW 66 
#define MAX_COLUMN 80 
int hour; 

int min; 

int sec; 

#include "mydefs.h" 


You can embed the definitions that appear in defs.h with the following directive: 
#include "defs.h" 


One of the ways you can combine the use of preprocessor directives is 
demonstrated in the following example. A #define is used to define a macro that 
represents the name of the C or C++ standard I/O header file. A #include is then 
used to make the header file available to the C or C++ program. 


#define IQO_HEADER <stdio.h> 


#include IO HEADER /* equivalent to specifying #include <stdio.h> */ 


Using the #include Directive When Compiling Source in an 
Integrated File System File 


You can use the SRCSTMF keyword to specify an Integrated File System file at 
compile time. The #include processing differs from source physical file processing 
in that the library list is not searched. The search path specified by the INCLUDE 
environment variable (if it is defined), and the compiler’s default search path are 
used to resolve header files. 


The compiler’s default include path is /QIBM/include. 

#include files use the delimiters "” or <>. 

When attempting to open the include file, the compiler searches in turn each 
directory in the search path until the file is found or all search directories have 


been exhausted. 


The algorithm to search for include files is: 
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if file is fully qualified (a slash / starts the name) then 
attempt to open the fully qualified file 
else 
if "" is delimiter, check job's current directory 
if not found: 
Loop through the list of directories specified in the INCLUDE environment variable 
and then the default include path 
until the file is found or the end of the include path is encountered 
endif 


For more information, refer to Using the ILE C/C++ Stream Functions With the 
AS/400 Integrated File System in ILE C/C++ Programmer's Guide. 


Conditional Compilation Directives 


A preprocessor conditional compilation directive causes the preprocessor to 
conditionally suppress the compilation of portions of source code. These directives 
test a constant expression or an identifier to determine which tokens the 
preprocessor should pass on to the compiler and which tokens should be bypassed 
during preprocessing. The directives are: 


° #if 

¢ #ifdef 
¢ #ifndef 
° #elif 

¢ #else 

° #endif 


The preprocessor conditional compilation directive spans several lines: 

* The condition specification line 

* Lines containing code that the preprocessor passes on to the compiler if the 
condition evaluates to a nonzero value (optional) 

* The #elif line (optional) 

¢ Lines containing code that the preprocessor passes on to the compiler if the 
condition evaluates to a nonzero value (optional) 

* The #else line (optional) 


* Lines containing code that the preprocessor passes on to the compiler if the 
condition evaluates to zero (optional) 


* The preprocessor #endif directive 


For each if, ifdef, and ifndef directive, there are zero or more elif directives, zero 
or one else directive, and one matching endif directive. All the matching directives 
are considered to be at the same nesting level. 


You can nest conditional compilation directives. In the following directives, the 
first #else is matched with the #if. 


#ifdef MACNAME 

/* tokens added if MACNAME is defined */ 
# if TEST <=10 

/* tokens added if MACNAME is defined and TEST <= 10 */ 


# else 

/* tokens added if MACNAME is defined and TEST > 10 */ 
# endif 
#else 

/* tokens added if MACNAME is not defined */ 
#endif 
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Each directive controls the block immediately following it. A block consists of all 
the tokens starting on the line following the directive and ending at the next 
conditional compilation directive at the same nesting level. 


Each directive is processed in the order in which it is encountered. If an expression 
evaluates to zero, the block following the directive is ignored. 


When a block following a preprocessor directive is to be ignored, the tokens are 
examined only to identify preprocessor directives within that block so that the 
conditional nesting level can be determined. All tokens other than the name of the 
directive are ignored. 


Only the first block whose expression is nonzero is processed. The remaining 
blocks at that nesting level are ignored. If none of the blocks at that nesting level 
has been processed and there is a else directive, the block following the else 
directive is processed. If none of the blocks at that nesting level has been processed 
and there is no else directive, the entire nesting level is ignored. 


#if, #elif 


The if and elif directives compare the value of the expression to zero. 


If the constant expression evaluates to a nonzero value, the tokens that 
immediately follow the condition are passed on to the compiler. 


If the expression evaluates to zero and the conditional compilation directive 
contains a preprocessor elif directive, the source text located between the elif and 
the next elif or else directive is selected by the preprocessor to be passed on to the 
compiler. The elif directive cannot appear after the else directive. 


All macros are expanded, any defined() expressions are processed and all 
remaining identifiers are replaced with the token 0. 


>>—#—_if constant_expression—token_sequence >< 
elif 


The expressions that are tested must be integer constant expressions with the 

following properties: 

* No casts are performed. 

* Arithmetic is performed using long int values. 

* The expression can contain defined macros. No other identifiers can appear in 
the expression. 


* The constant expression can contain the unary operator defined. This operator 
can be used only with the preprocessor keyword if or elif. The following 
expressions evaluate to 1 if the identifier is defined in the preprocessor, otherwise 
to 0: 


defined identifier 
defined (identifier) 


For example: 
#if defined(TEST1) || defined(TEST2) 
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Note: If a macro is not defined, a value of 0 (zero) is assigned to it. In the 
following example, TEST must be a macro identifier: 
#if TEST >= 1 
printf("i = %d\n", i); 
printf("array[i] = %d\n", array[i]); 
#elif TEST < 0 
printf("array subscript out of bounds \n"); 


#endif 
#ifdef 
The ifdef directive checks for the existence of macro definitions. 
If the identifier specified is defined as a macro, the tokens that immediately follow 
the condition are passed on to the compiler after a newline. 
The ifdef directive has the form: 
p>—#—i fdef—identifier—token_sequence >< 
The following example defines MAX_LEN to be 75 if EXTENDED is defined for the 
preprocessor. Otherwise, MAX_LEN is defined to be 50. 
#ifdef EXTENDED 
# define MAX_LEN 75 
#else 
# define MAX_LEN 50 
#endif 
#ifndef 


The ifndef directive checks for the existence of macro definitions. 


If the identifier specified is not defined as a macro, the tokens that immediately 
follow the condition are passed on to the compiler after a newline. 


The ifndef directive has the form: 


p>—#—i fndef—identifier— 


token_sequence >< 


An identifier must follow the #ifndef keyword. The following example defines 
MAX_LEN to be 50 if EXTENDED is not defined for the preprocessor. Otherwise, MAX_LEN 
is defined to be 75. 

#ifndef EXTENDED 

# define MAX_LEN 50 

#else 

# define MAX_LEN 75 

#endif 
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#else 


#endif 


If the condition specified in the if, ifdef, or ifndef directive evaluates to 0, and the 
conditional compilation directive contains a else directive, the source text located 
between the else and the endif directives is selected by the preprocessor to be 
passed on to the compiler. 


The else directive has the form: 


pp—#—else—™ 


token_sequence >< 


The endif directive ends the conditional compilation directive. 
It has the form: 


>>—#endif. >< 


Examples: Conditional compilation directives 


The following example shows how you can nest preprocessor conditional 
compilation directives: 


#if defined (TARGET1) 
define SIZEOF_INT 16 
ifdef PHASE2 

define MAX_PHASE 2 
else 

define MAX_PHASE 8 
endif 

elif defined (TARGET2) 
define SIZEOF_INT 32 
define MAX_PHASE 16 

else 
define SIZEOF_INT 32 
define MAX_PHASE 32 


SH OSHR OSH: SHE SHR SHR SHE SHR SHE SR SR HE 


The following program contains preprocessor conditional compilation directives: 
[** 
xx This example contains preprocessor 


** conditional compilation directives. 
**/ 


#include <stdio> 


int main(void) 

{ 
static int array[ ] = { 1, 2, 3, 4, 5}; 
int is; 


for (i = 0; i <= 4; i++) 
{ 


array[i] *= 2; 


#if TEST >= 1 
printf("i = %d\n", i); 
printf("array[i] = %d\n", array[i]); 
#endif 
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return(0); 


} 


Line Control (#line) 


A preprocessor line control directive supplies line numbers for compiler messages. It 
causes the compiler to view the line number of the next source line as the specified 
number. 


The line directive has the form: 


>< 


p>—i# 7 decimal_constant 
line 


LN Fi te tones! 


‘characters 


In order for the compiler to produce meaningful references to line numbers in 
preprocessed source, the preprocessor inserts line directives where necessary (for 
example, at the beginning and after the end of included text). 


A file name specification enclosed in double quotation marks can follow the line 
number. If you specify a file name, the compiler views the next line as part of the 
specified file. If you do not specify a file name, the compiler views the next line as 
part of the current source file. 


The token sequence on a line directive is subject to macro replacement. After 
macro replacement, the resulting character sequence must consist of a decimal 
constant, optionally followed by a file name enclosed in double quotation marks. 


Example: line directive 


You can use #line control directives to make the compiler provide more 
meaningful error messages. The following program uses #line control directives to 
give each function an easily recognizable line number: 

[** 


** This example illustrates #line directives. 
**/ 


#include <stdio.h> 
#define LINE200 200 


int main(void) 
{ 
func_1(); 
func_2(); 
} 


#line 100 
func_1() 
{ 


printf("Func_1 - the current line number is %d\n",  _LINE__); 


} 


#line LINE200 
func_2() 
{ 


printf("Func_2 - the current line number is %d\n",  _LINE__); 


} 
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This program produces the following output: 


Func_1 - the current line number is 102 
Func_2 - the current line number is 202 


Null Directive (#) 


The null directive performs no action. It consists of a single # on a line of its own. 


The null directive should not be confused with the # operator or the character that 
starts a preprocessor directive. 


Example: # (null) directive 


If MINVAL is a defined macro name, no action is performed. If MINVAL is not a 
defined identifier, it is defined 1. 


#ifdef MINVAL 

# 
#else 

#define MINVAL 1 
#endif 


Pragma Directives (#pragma) 
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A pragma is an implementation-defined instruction to the compiler. It has the 


general form: 
”_character_sequence >< 


where character_sequence is a series of characters giving a specific compiler 
instruction and arguments, if any. 


>>—#—pragma 


Unless specifically noted otherwise, character sequences in pragma directives are 
not case sensitive. For example, the following two pragma directives are 
functionally equivalent: 


#pragma convert (37) 
#pragma CoNvErT (37) 


The character_sequence on a pragma is subject to macro substitutions. For example, 


#define XX_ISO_DATA isolated_cal1(LG_ISO_DATA) 
ee 
#pragma XX_ISO_DATA 


More than one pragma construct can be specified on a single pragma directive. The 
compiler ignores unrecognized pragmas. 


ILE C/C++ pragmas are described in|Chapter 3, “ILE C/C++ Pragmas” on page 23 
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Chapter 2. Predefined Macros 


The ILE C/C++ compiler recognizes the predefined macros described in this 


chapter. 


* |“ ANSI/ISO Standard Predefined Macros” 
° |“ILE C/C++ Predefined Macros” on page 18 


ANSI/ISO Standard Predefined Macros 


The ILE C/C++ compiler recognizes the following macros defined by the 
ANSI/ISO Standard. Unless otherwise specified, macros when defined have a 


value of 1. 


__ DATE __ 


FILE 


LINE _ 


STDC __ 


_ TIME __ 


__cplusplus 


© Copyright IBM Corp. 1993, 2002 


A character string literal containing the date when the source file 
was compiled. The date will be in the form: 


"Mmm dd yyyy" 
where: 


Mmm represents the month in an abbreviated form (Jan, Feb, Mar, 
Apr, May, Jun, Jul, Aug, Sep, Oct, Nov, or Dec). 


dd represents the day. If the day is less than 10, the first d will be a 
blank character. 
yyyy represents the year. 


Defined as a character string literal containing the name of the 
source file. 


Defined to be an integer representing the current source line 
number. 


Defined if the C compiler conforms to the ANSI standard. This 
macro is undefined if the language level is set to anything other 
than ANSI. 


Defined as a character string literal containing the time when the 
source file was compiled. The time will be in the form: 


"hh:mm:ss" 
where: 
hh represents the hour. 
mm represents the minutes. 


ss represents the seconds. 


Defined when compiling a C++ program, indicating that the 
compiler is a C++ compiler. Note that this macro has no trailing 
underscores. This macro is not defined for C. 
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Notes: 


1. Predefined macro names cannot be the subject of a #define or #undef 
preprocessor directive. 


2. The predefined ANSI/ISO Standard macro names consist of two underscore 
(__) characters immediately preceding the name, the name in uppercase letters, 
and two underscore characters immediately following the name. 


3. The value of _ LINE will change during compilation as the compiler 
processes subsequent lines of your source program. 


4. The value of _ FILE, and __TIMESTAMP__ will change as the compiler 
processes any #include files that are part of your source program. 


5. You can also change _ LINE__ and __FILE__ using the #line preprocessor 
directive. 


Examples 


The following printf() statements will display the values of the predefined 
macros _LINE_, __FILE_, TIME, and _ DATE__ and will print a message 
indicating the program’s conformance to ANSI standards based on __STDC_: 


#include <stdio.h> 

#ifdef — STDC__ 

# define CONFORM "conforms" 

#else 

# define CONFORM "does not conform" 
#endif 

int main(void) 


printf("Line %d of file %s has been executed\n", LINE, _ FILE_); 


printf("This file was compiled at %s on %s\n", _ TIME, _ DATE_); 
printf("This program %s to ANSI standards\n", CONFORM) ; 


Related Information 


“#define (Defining and Expanding a Macro)” on page 2 


“#undef (Undefining a Macro)” on page 5 
“Line Control (#line)” on page 15 
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The ILE C/C++ compiler provides the predefined macros described in this section. 
These macros are defined when their corresponding pragmas are invoked in 
program source, or when their corresponding compiler options for the Create 
Module and Create Bound Program commands are specified. Unless otherwise 
specified, macros when defined have a value of 1. 


__ANST __ Defined when the LANGLVL(*ANSI) compiler option is in effect. 
When this macro is defined, the compiler allows only language 
constructs that conform to the ANSI/ISO C and C++ standards. 


__ASYNC_SIG__ For C programs only, this macro is defined when the 
SYSIFCOPT(?*ASYNCSIGNAL) compiler option is in effect. This 
macro is not defined for C++. 


_CHAR_SIGNED Defined when the #pragma chars(signed) directive is in effect, or 
when the DFTCHAR compiler option is set to *SIGNED. If this 
macro is defined, the default character type is signed. 
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_CHAR_UNSIGNED 


__COMPAT __ 


__EXTENDED _ 


__FUNCTION__ 


__HHW_AS400_ 
__HOS_0S400__ 
__IBMCPP__ 
_IFS_10__ 


_1FS64_10 __ 


__ILEC400__ 


Defined when the #pragma chars(unsigned) directive is in effect, 
or when the DFTCHAR compiler option is set to *UNSIGNED. 
Indicates default character type is unsigned. 


For C++ programs only, this macro is defined when the 
LANGLVL(*LEGACY) compiler option is in effect together with 
one of the following options: 

* TGTRLS(*PRV) 

* TGTRLS(V4R5MO0) 

* TGTRLS(V4R4M0) 


When this macro is defined, the compiler allows language 
extensions compatible with earlier versions of the C++ language. 
This macro is not defined for C. 


Defined when the LANGLVL(*EXTENDED) compiler option is in 
effect. When this macro is defined, the compiler allows language 
extensions provided by the ILE C/C++ compiler implementation. 


Indicates the name of the function currently being compiled. For 
C++ programs, expands to the actual function prototype. 


Indicates that the host hardware is an iSeries processor. 
Indicates that the host operating system is OS/400. 
Indicates the version number of the ILE C/C++ compiler. 


Defined when SYSIFCOPT(*IFSIO) or SYSIFCOPT(*IFS64IO) is 
specified on the Create Module or Create Bound Program 
commands. 


Defined when SYSIFCOPT(*IFS64IO) is specified on the Create 
Module or Create Bound Program commands. When this macro is 
defined, LARGE FILES and _LARGE_FILE API are also defined 
in the relevant IBM-supplied header files. 


Defined only by the compiler. You can use this macro in source 
code that is compiled for several platforms to mark code that is to 
be compiled only for the iSeries platform with #ifdef _ ILEC400__ 
or, #if defined, (__ILEC400__) preprocessor directives. 


__ILEC400_TGTVRM__ 


_LARGE_FILES 


Defined by the compiler as an integral value that maps to the 
version/release/modification of the OS/400® that the module or 
program being compiled is intended to run on. The target release, 
VxRyMz, translates to an _ILEC400_TGTVRM_ value of xyz, 
where x, y, and z are integer values. For example, a target release 
of V3R7MO will cause the macro to have an integral value of 370. 


Defined when the SYSIFCOPT(*IFS64IO) compiler option is in 
effect. 


_LARGE_FILE_API 


__LLP64_IFC__ 
__LONG_LONG__ 


Defined when the SYSIFCOPT(*IFS64IO) compiler option is in 
effect. 


Defined when the DTAMDL(*LLP64) compiler option is in effect. 


Defined when the LANGLVL(*EXTENDED) compiler 
option is in effect. 
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__0S400__ 


Defined when the OPTION(*LONGLONG) compiler 
option is in effect. 


This macro is always defined when the compiler is used with the 
OS/400 operating system. 


__0S400_TGTVRM__ 


Defined only by the compiler as an integral value that maps to the 
version/release/modification of the OS/400® that the module or 
program being compiled is intended to run on. The target release, 
VxRyMz, translates to an __OS400_TGTVRM_ value of xyz, where 
x, y, and z are integer values. 


__POSIX_LOCALE__ 


Defined when the LOCALETYPE(*LOCALE) or 
LOCALETYPE(*LOCALEUCS2) compiler options are specified. 


__RTTI_DYNAMIC_CAST__ 


__SRCSTMF__ 


__TERASPACE_ 


__THW_AS400__ 
__TIMESTAMP__ 


__TOS_0S400__ 
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Defined when the OPTION(*RTTIALL) or OPTION(*RTTICAST) 
compiler options are specified, for C++ programs only. This macro 
is not defined for C. 


Defined when the SRCSTMF compiler option specifies the location 
of the source file being compiled. 


Defined when the TERASPACE(*YES *TSIFC) compiler option is 
specified. 


Indicates that the target hardware is an iSeries processor. 


A character string literal containing the date and time when the 
source file was last changed. 


The date and time will be in the form: 
"Day Mmm dd hh:mm:ss yyyy" 


where: 


Day represents the day of the week (Mon, Tue, Wed, Thu, Fri, Sat, or 
Sun). 


Mmm represents the month in an abbreviated form (Jan, Feb, Mar, 
Apr, May, Jun, Jul, Aug, Sep, Oct, Nov, or Dec). 


dd represents the day. If the day is less than 10, the first d will be a 
blank character. 


hh represents the hour. 

mm represents the minutes. 

ss represents the seconds. 

yyyy represents the year. 

Note: Other compilers may not supported this macro. If the macro 


is supported on other compilers, the date and time values 
may be different than those that are shown here. 


Indicates that the target operating system is OS/400. 


UGS? Defined when LOCALETYPE(*LOCALEUCS2) is specified on the 
Create Module or Create Bound Program commands. 


__wchar_t Defined when TGTRLS(*CURRENT) is specified on the Create 
Module or Create Bound Program commands. The wchar_t built-in 
type is available when this macro is defined. 
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Chapter 3. ILE C/C++ Pragmas 


The ILE C/C++ Compiler recognizes the following pragmas: 


Valid with Valid with 


Pragma Name _- 


! 


“argopt” on page 2 a 


an 


“argument” on page 2 


“cancel_handler” on page 2 


\ 


N 


“chars” on page 2 


“checkout” on page 28 


X 


“comment” on page 29 


“convert” on page 3 
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“enumsize” on page 3 al 


“exception_handler” on page 40 a 


“hashome” on page 4 


“implementation” on page 44 


iS 


“import” on page 4 


VI NP XP XT 


“info” on page 45 


“inline” on page 46 a 


! 
\ 


“ishome” on page 4 


\ 


“isolated_call” on page 47 


| 


“linkage” on page 4 


4 


map” on page 49 


“mapinc” on page 4 


“margins” on page 5 


ie?) 
X 


“namemangling” on page 5 


[o) 
Ol 
ise) 


“noargv0O” on pag 


“noinline (function)” on page 54 


“nomargins” on page 5: 


“nosequence” on page 55 


cs 
VIX PX XTX 


Ol 


“nosigtrunc” on page 5 


\ 


“object_model” on page 55 
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Valid with Valid with 


Pragma Name 


7 7 
7 
7 
7 7 
+ 
“sequence” on page 64 a 
“skip” on page 64 a 


\ 


“strings” on page 65 a 


\ 


“weak” on page 6 


argopt 
ces 
>>—#pragma argopt—(———function_name ) >< 
|-typedef_of_function_name— 
| -typedef_of_function_ptr— 
function_ptr 
Description 


Argument Optimization (argopt) is a pragma which may improve run-time 
performance. Applied to a bound procedure, optimizations can be achieved by: 
* Passing space pointer parameters in to general-purpose registers (GPRs). 

* Storing a space pointer returned from a function in to a GPR. 


function_name Specifies the name of the function for which optimized procedure 
parameter passing is to be specified. The function can be either a 
static function, an externally-defined function, or a function 
defined in the current compilation unit that will be called from 
outside the current compilation unit. 


typedef_of_function_name 
Specifies the name of the typedef of the function for which 


optimized procedure parameter passing is to be specified. 


typedef_of_function_ptr 
Specifies the name of the typedef of the function pointer for which 


optimized procedure parameter passing is to be specified. 


function_ptr Specifies the name of the function pointer for which optimized 
procedure parameter passing is to be specified. 


Notes on Usage 


Specifying #pragma argopt directive does not guarantee that your program will be 
optimized. Participation in argopt is dependent on the translator. 
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A function must be declared (prototyped), or defined before it can be named in a 
#pragma argopt directive. 


A structure greater than 8 bytes will not fit in a GPR. 
Void pointers will not be optimized since they are not space pointers. 


The #pragma argopt cannot be specified for functions which have OS-linkage or 
built-in linkage (for functions which have a #pragma linkage (function_name, OS) 
directive or #pragma linkage(function_name, builtin) directive associated with 
them, and vice versa). 


The #pragma argopt will be ignored for functions which are named as handler 
functions in #pragma exception_handler or #pragma cancel_handler directives, and 
error handling functions such as signal() and atexit(). The #pragma argopt 
directive cannot be applied to functions with a variable argument list. 


#pragma argopt scoping 


The #pragma argopt is placed where the function, the function pointer, typedef of 
a function pointer or typedef of an function is visible (can be used) within a region 
of the program code called its scope. #pragma argopt scope is determined its 
placement in the code. An error will be issued when #pragma argopt is not within 
the scope of the declaration. The #pragma argopt directive can fall within file, 
block, or structure scope. 


#include <stdio.h> 


long func3(long y) 

{ 

printf("In func3()\n"); 

printf ("hex=%x,integer=%d\n",y, y)3 

} 

#pragma argopt (func3) /* file scope of function */ 
int main(void) 


{ 


int i, a=0; 
typedef long (*func_ptr) (long); 
#pragma argopt (func_ptr) /* block scope of typedef = */ 


/* of function pointer */ 
struct funcstr 
{ 
long (*func_ptr2) (long); 
#pragma argopt (func_ptr2) /* struct scope of function */ 
/* pointer */ 
bs 
struct funcstr func_ptr3; 
for (i=0; 1<99; i++) 
{ 
a= ixi; 
if G7) 
{ 
func_ptr3.func_ptr2 = func3; 
func_ptr3.func_ptr2( i ); 
} 
} 
return i; 


} 
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argument 


>>—#—_pragma—argument—(—function_name »—OS 7 ) >< 
L__,—nowiden 
>—VREF- 
E —iourdare 
»>—nowiden 
Description 


Specifies the argument passing/receiving mechanism to be used for the procedure 
or typedef named by function_name. 


This pragma identifies procedures as externally bound-procedures only. The 
procedure may be defined in and/or called from the same source as the pragma 
argument directive. If the pragma argument directive is specified in the same 
compilation unit as the definition of the procedure named in that directive, the 
arguments to that procedure will be received using the method specified in that 
pragma directive. 


For information on making calls to external programs, see pragma[“linkage” on] 


Parameters 
function_name Specifies the name of the externally-bound procedure. 


OSs OS indicates that arguments are passed, or received (if the pragma 
directive is in the same compilation unit as the procedure 
definition), using the OS-Linkage argument method. Non-address 
arguments are copied to temporary locations and widened (unless 
nowiden has been specified), and the address of the copy is passed 
to the called procedure. Arguments that are addresses or pointers 
are passed directly to the called procedure. 


VREF VREF is similar to OS-linkage with the exception that address 
arguments are also passed/received using the OS-Linkage method. 


nowiden Specifies that the arguments are not widened before they are 
passed or received. This parameter can be used by itself without 
specifying an argument type. For example, #pragma argument 
(myfunc, nowiden), indicates that procedure myfunc will pass 
and/or receive its arguments with the usual by-value method, but 
unwidened. 


Notes on Usage 

A function name specified in the #pragma argument directive can be defined in the 
current compilation unit. This pragma controls how parameters are passed to 
bound-procedures and how they are received. 

Specifying a #pragma argument directive in the same compilation unit as the 


affected procedure tells the compiler that the procedure is to receive (as well as to 
send) its arguments as specified in the pragma argument directive. This is useful 
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for ILE C written bound-procedures specified in a pragma argument. The user 
must ensure that if the call to the procedure and the definition are in separate 
compilation units, the pragma argument directives must match in regards to their 
passing method ( OS, VREF, and nowiden). 


For example, in the two source files below, the address of a temporary copy of the 
argument will be passed to ‘foo’ in Program 1. Program 2, ‘foo’ will receive the 
address of the temporary copy, dereference it, and assign that value to the 
parameter ‘a’. If the two pragma directives differ, behavior is undefined. 


Program 1 Program 2 
#pragma argument( foo, OS, nowiden) #pragma argument( foo, OS, nowiden ) 
void foo(char); void foo( char a ) { att; } 
void main() { 
foo(10); 
} 


Warnings are issued, and the #pragma argument directive is ignored if any of the 
following occurs: 


* The function_name in the directive is not the name of a procedure or a typedef of 
a procedure. 


* A typedef named in the directive has been used in the declaration or definition 
of a procedure before being used in the directive. 


* A #pragma argument directive has already been specified for this function. 


* A #pragma linkage directive or _System keyword has already been specified for 
this function. 


* The function has already been called prior to the #pragma argument directive. 


cancel_ handler 
C++ 


>>—#—pragma—cancel_handler—(—function_name 0 7 ) >< 
»—com_area 


Description 


Specifies that the function named is to be enabled as a user-defined ILE cancel 
handler at the point in the code where the #pragma cancel_handler directive is 
located. 


Any cancel handler that is enabled by a #pragma cancel_handler directive is 
implicitly disabled when the call to the function containing the directive is 
finished. The call is removed from the call stack, if the handler has not been 
explicitly disabled by the #pragma disable_handler directive. 


Parameters 


function_name Specifies the name of the function to be used as a user-defined ILE 
cancel handler. 


com_area Used to pass information to the exception handler. If no com_area is 
required, specify zero as the second parameter of the directive. If a 
com_area is specified on the directive, it must be a variable of one 
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of the following data types: integral, float, double, struct, union, 
array, enum, pointer, or packed decimal. The com_area should be 
declared with the volatile qualifier. It cannot be a member of a 
structure or a union. 


See the Run-Time Library Reference for information about <except.h> and the 
typedef _CNL_Hndlr_Parms_T, a pointer which is passed to the cancel handler. 


Notes on Usage 


This #pragma directive can only occur at a C language statement boundary and 
inside a function definition. 


The compiler issues an error message if any of the following occurs: 

* The directive occurs outside a C function body or inside a C statement. 
* The handler function is not declared or defined. 

* The identifier that is named as the handler function is not a function. 

* The com_area variable is not declared. 

* The com_area variable does not have a valid object type. 


See the ILE C/C++ Programmer's Guide for examples and more information about 
using the #pragma cancel_handler directive. 


chars 


checkout 


is 2: 

>>—#—pragma—chars—( Signed 7 ) >< 
‘_unsigned 

Description 


Specifies that the compiler is to treat all char objects as signed or unsigned. This 
pragma must appear before any C code or directive (except for the #line directive) 
in a source file. 


Parameters 
signed All char objects are treated as signed integers. 
unsigned All char objects are treated as unsigned integers. 


- c| 


>>—#—pragma—checkout—( al ) >< 
‘_resume 


Description 


28 ILE C/C++ Compiler Reference 


Specifies whether or not the compiler should give compiler information when a 
CHECKOUT setting other than *NONE is specified for the Create Module or 
Create Bound Program commands. 


Parameters 
suspend Specifies that the compiler suspend informational messages. 
resume Specifies that the compiler resume informational messages. 


Notes on Usage 


#pragma checkout directives can be nested. This means that a #pragma checkout 
(suspend) directive will have no effect if a previously specified #pragma checkout 
(suspend) directive is still in effect. This is also true for the #pragma checkout 
resume directive. 


Example 

/* Assume CHECKOUT(*PPTRACE) had been specified */ 
#pragma checkout(suspend) /* No CHECKOUT diagnostics are performed */ 
#pragma checkout(suspend) /* No effect x/ 
#pragma checkout(resume) /* No effect x/ 


#pragma checkout(resume) | /* CHECKOUT(*PPTRACE) diagnostics continue */ 


comment 


C++ 
>>—#—pragma—comment— ( compiler. ) > 
date 
‘_timestamp— 
—copyright 
user. »>—"—characters—" 
Description 


Emits a comment into the program or service program object. This can be shown 
by DSPPGM or DSPSRVPGM with DETAIL“(COPYRIGHT). This pragma must 
appear before any C code or directive (except for the #line directive) in a source 
file. 


Parameters 


Valid settings for the comment pragma can be: 


compiler The name and version of the compiler is emitted into the end of 
the generated program object. 


date The date and time of compilation is emitted into the end of the 
generated program object. 


timestamp The last modification date and time of the source is emitted into 
the end of the generated program object. 
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copyright The text that is specified by characters is placed by the compiler 
into the generated program object and is loaded into memory 
when the program is run. 


user The text specified by characters is placed by the compiler into the 
generated object. However, it is not loaded into memory when the 
program is run. 


Notes on Usage 

* The copyright and user comment types are virtually the same for the ILE C/C++ 
compiler. One has no advantage over the other. 

* The maximum number of characters in the text portion of a #pragma 
comment(copyright) or #pragma comment(user) directive is 256. 

* The maximum number of #pragma comment directives that can appear in a 
single compilation unit is 1024. 


convert 


= 


>>—#—pragma—convert—(—ccsid—) >< 


Description 


Specifies the Coded Character Set Identifier (CCSID) to use for converting the 
string literals from that point onward in a source file during compilation. The 
conversion continues until the end of the source file or until another #pragma 
convert directive is specified. Use #pragma convert (0) to disable the previous 
#pragma convert directive. The CCSID of the string literals before conversion is the 
same CCSID as the root source member. CCSIDs 905 and 1026 are not supported. 
The CCSID can be either EBCDIC or ASCII. 


Parameters 


ccsid Specifies the coded character set identifier to use for converting the 
strings and literals in the source file. The value may range between 
0 and 65535. See the ILE C for AS/400 Run-Time Library Reference 
manual for more information about code pages. 


Notes on Usage 


The run-time library functions that parse format strings (such as printf() and 
scanf()) cannot use ASCII format strings. Therefore, all format strings must be in 
EBCDIC. 


String and character constants that are specified in hex, for example (0xC1), are not 
converted. 


Substitution characters will not be used when converting to a target CCSID that 
does not contain the same symbol set as the source CCSID. The compilation will 
fail. 


If a CCSID with the value 65535 is specified, the CCSID of the root source member 
is assumed. If the source file CCSID value is 65535, the job CCSID is assumed for 
the source file. If the file CCSID is 65535 and the job CCSID is not 65535, the job 
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CCSID is assumed for the file CCSID. If the file is 65535 and the job is also 65535, 
but the system CCSID value is not 65535, the system CCSID value is assumed for 
the file CCSID. If the file, job and system CCSID values are 65535, CCSID 037 is 
assumed. 


If the LOCALETYPE(*LOCALEUCS2) option is specified for the Create Module or 
Create Bound Program commands, wide-character literals are not converted. See 
Using Unicode Support for Wide-Character Literals in ILE C/C++ Programmer’s Guide 
for more information. 


datamodel 


C++ 

P128 
>>—#—pragma—datamodel—( LLP64 ) >< 
Description 


Specifies a data model to apply to a section of code. The data model setting 
determines the interpretation of pointer types in absence of an explicit modifier. 


This pragma overrides the data model specified by the DIAMDL compiler 
command line option. 
Parameters 


P128, p128 Default setting. If specified, sizes of int, long, and pointer types in 
program code following this pragma are 4, 4, and 16 bytes 
respectively, until another pragma datamodel setting is specified. 


LLP64, Ilp64 __If specified, sizes of int, long, and pointer types in program code 
following this pragma are 4, 4, and 8 bytes respectively, until 
another pragma datamodel setting is specified. 


pop Restores the previous data model setting. If there is no previous 
data model setting, the setting specifed by the DIAMDL compiler 
command line option is used. 


Note on Usage 


This pragma and its settings are case-sensitive when used in C++ 
programs. 


Specifying #pragma datamodel(LLP64) or #pragma datamodel(llp64) has effect 
only when the TERASPACE(*YES) compiler option is also specified. 


The data model specified by this pragma remains in effect until another data 
model is specified, or until pragma datamodel(pop) is specified. 


Example 
This pragma is recommended for wrapping header files, without having to add 


pointer modifiers to pointer declarations. For example: 
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// header file blah.h 


#pragma datamodel (P128) // Pointers are now 16-byte 
char* Blah(int, char *); 
#pragma datamodel (pop) // Restore previous setting of datamodel 


You can also specify data models using the __ptr64 and __ptr128 pointer modifiers. 
These modifers override the DTAMDL compiler option, and the #pragma 
datamodel setting for a specific pointer declaration. 


The __ptr64 modifier should only be used if the TERASPACE(*YES) compiler 
option is also specified. The __ptr128 modifier can be used at any time. 


The following example shows the declarations of a process local pointer and a 
tagged space pointer: 


char * _ptr64_ p; // an 8-byte, process local pointer 
char * _ptrl128 t; // a 16-byte, tagged space pointer 


For more information, see Using Teraspace in ILE C/C++ Programmer’s Guide, and 
Teraspace and single-level store in ILE Concepts. 


define 
C++ 

>>—#—pragma—define—(—template_class_name—) >< 
Description 
The #pragma define directive forces the definition of a template class without 
actually defining an object of the class. The pragma can appear anywhere that a 
declaration is allowed. It is used when organizing your program for the efficient or 
automatic generation of template functions. 

descriptor 


C++ 


>>—#—pragma—descriptor—(—void—funct ton_name—(— od_specifiers [-) —)——»>< 


od_ specifiers: 


| 
cl | 
Lx. 
Vv nu 


Description 


An operational descriptor is an optional piece of information that is associated 
with a function argument. This information is used to describe an argument’s 
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attributes, for example, its data type, and length. The #pragma descriptor directive 
is used to identify functions whose arguments have operational descriptors. 


Operational descriptors are useful when passing arguments to functions that are 
written in other languages that may have a different definition of the data types of 
the arguments. For example, C defines a string as a contiguous sequence of 
characters ended by and including the first null character. In another language, a 
string may be defined as consisting of a length specifier and a character sequence. 
When passing a string from a C function to a function written in another language, 
an operational descriptor can be provided with the argument to allow the called 
function to determine the length and type of the string being passed. 


The ILE C/C++ compiler generates operational descriptors for arguments that are 
passed to a function specified in a #pragma descriptor directive. The generated 
descriptor contains the descriptor type, data type, and length for each argument 
that is identified as requiring an operational descriptor. The information in an 
operational descriptor can be retrieved by the called function using the ILE APIs 
CEEGSI and CEEDOD. For more information about CL commands, see the CL and 
APIs section in the Programming category at the iSeries 400 Information Center Web 
site: 

http://publib. boulder. ibm.com/pubs/htm1/as400/infocenter. htm 


For the operational descriptor to determine the correct string length when passed 
through a function, the string has to be initialized. 


The ILE C compiler supports operational descriptors for describing strings. 


Note: A character string in ILE C/C++ is defined by using any one of the 
following: 


* char string _name[n] 
* char * string_name 
* A string literal. 


Parameters 


function_name The name of the function whose arguments require operational 
descriptors. 


od_specifiers A list of symbols, that consists of "”, void, or *, separated by 
commas, that specify which of a function’s arguments are to have 
operational descriptors. An od_specifier list is similar to the 
argument list of a function except that an od_specifier list for a 
function can have fewer specifiers than its argument list. 


we 


* Ifa string operational descriptor is required for an argument, 
or * should be specified in the equivalent position for the 
od_specifier parameter. 


* If an operational descriptor is not required for an argument then 
void is specified for that parameter in the equivalent position for 
the od_specifier list. 


Notes on Usage 


The compiler issues a warning and ignores the #pragma descriptor directive if any 
of the following conditions occur: 


* The identifier specified in the pragma directive is not a function. 
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The function is already specified in another pragma descriptor. 

The function is declared as static. 

The function has already been specified in a pragma linkage directive. 
The function specified is a user entry procedure, for example, main(). 
The function is not prototyped before its #pragma descriptor directive. 
A call to the function occurs before its #pragma descriptor directive. 


When using operational descriptors consider the following: 


Operational descriptors are only generated for functions that are called by their 
function name. Functions that are called by function pointer do not have 
operational descriptors generated. 


Operational descriptors are not allowed for C++ function declaration. 


If there are fewer od_specifiers than function arguments, the remaining 
od_specifiers default to void. 


If a function requires a variable number of arguments, the #pragma descriptor 
directive can specify that operational descriptors are to be generated for the 
required arguments but not for the variable arguments. 


It is not valid to do pointer arithmetic on a literal or array while it is also used 
as an argument that requires an operational descriptor, unless explicitly cast to 
char *. For example, if F is a function that takes as an argument a string, and F 
requires an operational descriptor for this argument, then the argument on the 
following call to F is not valid: F(a + 1) where "a" is defined as char a[10]. 


disable_handler 
= 


>>—#—pragma—disable_handler 


Description 


Disables the handler most recently enabled by either the exception_handler or 
cancel_handler pragma. 


This directive is only needed when a handler has to be explicitly disabled before 
the end of a function. This is done since all enabled handlers are implicitly 
disabled at the end of the function in which they are enabled. 


Notes on Usage 


This pragma can only occur at a C language statement boundary and inside a 
function definition. The compiler issues an error message if the #pragma 
disable_handler is specified when no handler is currently enabled. 


disjoint 


>>—#—pragma—disjoint 


C++ 


>< 
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vy 


>—( identifier ; * identifier ) >< 


Description 


This directive informs the compiler that none of the identifiers listed shares the 
same physical storage, which provides more opportunity for optimizations. If any 
identifiers actually share physical storage, the pragma may cause the program to 
give incorrect results. 


An identifier in the directive must be visible at the point in the program where the 
pragma appears. 9 The identifiers in the disjoint name list cannot refer to any of 
the following: 


* a member of a structure, or union 

* a structure, union, or enumeration tag 
* an enumeration constant 

* a typedef name 

* a label 


Example 
int a, b, *ptr_a, *ptr_b; 
#pragma disjoint(*ptr_a, b) // *ptr_a never points to b 
#pragma disjoint(*ptr_b, a) // *ptr_b never points to a 
one_function() 


b = 6; 
*ptr_a = 7; // Assignment does not alter the value of b 
another_function(b) ; // Argument "b" has the value 6 


} 


Because external pointer ptr_a does not share storage with and never points to the 
external variable b, the assignment of 7 to the object that ptr_a points to will not 
change the value of b. Likewise, external pointer ptr_b does not share storage with 
and never points to the external variable a. The compiler can assume that the 
argument of another_function has the value 6 and will not reload the variable from 
memory. 


entry 


C++ 


>>—#—pragma—entry—(—function_name—) >< 


Description 
Specifies the function to be used as the entry point for the application being built. 


The function_name is the name of the function to be used as an entry point. This 
function must be in the same compilation unit as the #pragma entry directive. The 
following types of functions cannot be used with #pragma entry: 


* functions with C++ linkage 
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* C++ member functions 
* template member functions 


* overloaded functions 


Normally when an application is started, the system calls the C library entry point. 
When you specify a different entry point using #pragma entry, the system calls 
that entry point and does not perform any C library initialization or termination. If 
you use #pragma entry, you must ensure that your executable file does not require 
library initialization or termination, or you must provide your own initialization 
and termination functions. 


enum 


Ce 


>>—#pragma—enum—( 1 
2 
4 

int 

smal] 

pop 
system_default— 
user_defaul t—— 


Description 


Specifies the number of bytes the compiler uses to represent enumerations. The 
pragma affects all subsequent enum definitions until the end of the compilation 
unit or until another #pragma enumsize directive is encountered. If more than one 
pragma is used, the most recently encountered pragma is in effect. This pragma 
overrides the ENUM compiler option, described on page 


Note: The enum pragma replaces the enumsize pragma. Support for the enumsize 
pragma may be removed in future releases. 


Parameters 


1,2,4 Specifies that enumerations be stored in 1, 2, or 4-byte containers. The sign 
of the container is determined by the range of values in the enumeration, 
but preference is given to signed when the range permits either. 


int Causes enumerations to be stored in the ANSI C or C++ Standard 
representation of an enumeration, which is 4-bytes signed. In C++ 
programs, the int container may become 4-bytes unsigned if a value in the 
enumeration exceeds 2°!-1, as per the ANSI C++ Standard. 


small Causes subsequent enumerations to be placed into the smallest possible 
container, given the values in the enumeration. The sign of the container is 
determined by the range of values in the enumeration, but preference is 
given to unsigned when the range permits either. 


pop __ Selects the enumeration size previously in effect, and discards the current 
setting. 


system_default 
Selects the default enumeration size, which is the smal] option. 
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user_default 
Selects the enumeration size specified by the ENUM compiler option. 


The value ranges that can be accepted by the enum settings are shown below: 


Enum Options 
Range of Element i 
Values oma ‘ 
(default) . 7 : mnt 
9 127 1 byte 1 byte 2 bytes 4 bytes 4 bytes signed 
unsigned signed signed signed 
0 2%. 255 4 byte f byte 2 bytes ‘ Bytes 4 bytes signed 
unsigned | unsigned signed signed 
-128 .. 127 peyts E byes z Dyes pyees 4 bytes signed 
signed signed signed signed 
0 .. 32767 e nye ERROR e Pye - press 4 bytes signed 
unsigned signed signed 
0 .. 65535 2 bytes | error | 2 bytes | 4 bytes | 4 bytes signed 
unsigned unsigned signed 
-32768 .. 32767 | © PYteS | ERROR error | 7 YES | 4 bytes signed 
signed signed 
0 .. 2147483647 | 7 bytes ERROR error | 7 YES | 4 bytes signed 
unsigned signed 
C++ 4 bytes 
0 .. 4294967295 | * bytes | eRpop Error | 4 bytes unsigned 
unsigned unsigned 
C ERROR 
-2147483648 .. 4 bytes 4 bytes 4 bytes : 
2147483647 signed ERROR signed signed a Bynes sagned 


Examples 


The examples below show various uses of the enum pragma and compiler options: 


1. You cannot change the storage allocation of an enum using a pragma enum 
within the declaration of an enum. The following code segment generates a 
warning and the second occurrence of the enum option is ignored: 

#pragma enum ( small ) 
enum e_tag { a, b, 
#pragma enum ( int ) /* error: cannot be within a declaration */ 
c 
} evar; 


#pragma enum ( pop ) /* second pop isn't required «/ 
2. The range of enum constants must fall within the range of either unsigned int 
or int (signed int). For example, the following code segments contain errors: 


#pragma enum ( small ) 
enum e_tag { a=-1, 
b=2147483648 /* error: larger than maximum int */ 
} evar; 
#pragma enum ( pop ) 
3. The enum constant range does not fit within the range of an unsigned int. 
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#pragma enum ( small ) 
enum e_tag { a=0, 
b=4294967296 /* error: larger than maximum int */ 
} evar; 
#pragma enum ( pop ) 
One use for the pop option is to pop the enumeration size set at the end of an 
include file that specifies an enumeration storage different from the default in 
the main file. For example, the following include file, small_enum.h, declares 
various minimum-sized enumerations, then resets the specification at the end 
of the include file to the last value on the option stack: 
#ifndef small_enum_h 
#define small_enum_h 
/* 
* File small_enum.h 
* This enum must fit within an unsigned char type 


#pragma enum ( small ) 
enum e_tag {a, b=255}; 
enum e_tag u_char_e var; /* occupies 1 byte of storage */ 


/* Pop the enumeration size to whatever it was before */ 
#pragma enum ( pop ) 
#endi f 


The following source file, int_file.c, includes small_enum.h: 
/* 
* File int_file.c 
* Defines 4 byte enums 
*/ 
#pragma enum ( int ) 
enum testing {ONE, TWO, THREE}; 
enum testing test_enum; 


/* various minimum-sized enums are declared «/ 
#include "small_enum.h" 


/* return to int-sized enums. small_enum.h has popped the enum size 
x/ 

enum sushi {CALIF_ROLL, SALMON ROLL, TUNA, SQUID, UNI}; 

enum sushi first_order = UNI; 


The enumerations test_enum and first_order both occupy 4 bytes of storage 
and are of type int. The variable u_char_e_var defined in small_enum.h 
occupies 1 byte of storage and is represented by an unsigned char data type. 
If the code fragment below is compiled with the ENUM = *SMALL option: 
enum e_tag {a, b, c} e var; 


the range of enum constants is 0 through 2. This range falls within all of the 
ranges described in the table above. Based on priority, the compiler uses 
predefined type unsigned char. 

If the code fragment below is compiled with the ENUM = *SMALL option: 
enum e_tag {a=-129, b, c} e var; 


the range of enum constants is -129 through -127. This range only falls within 
the ranges of short (signed short) and int (signed int). Because short (signed 
short) is smaller, it will be used to represent the enum. 

If you compile a file myprogram.c using the command: 

CRTBNDC MODULE (MYPROGRAM) SRCMBR(MYPROGRAM) ENUM(*SMALL) 
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all enum variables within your source file will occupy the minimum amount of 
storage, unless #pragma enum directives override the ENUM option. 
8. If you compile a file yourfile.c that contains the following lines: 


enum testing {ONE, TWO, THREE}; 
enum testing test_enum; 


#pragma enum ( small ) 
enum sushi {CALIF_ROLL, SALMON ROLL, TUNA, SQUID, UNI}; 
enum sushi first_order = UNI; 


#pragma enum ( int ) 
enum music {ROCK, JAZZ, NEW_WAVE, CLASSICAL}; 
enum music listening_type; 


using the command: 
CRTBNDC MODULE(YOURFILE) SRCMBR(YOURFILE) 


the enum variables test_enum and first_order will be minimum-sized (that is, 
each will only occupy 1 byte of storage). The other enum variable, 
listening_type, will be of type int and occupy 4 bytes of storage. 


enumsize 


>>—#pragma—enums i ze—( ) = 
1 
2 
LA 
Description 


Specifies the number of bytes the compiler uses to represent enumerations. The 
pragma affects all subsequent enum definitions until the end of the compilation 
unit or until another #pragma enumsize directive is encountered. If more than one 
pragma is used, the most recently encountered pragma is in effect. This pragma 
overrides the ENUM compiler option, described on page 


Note: The enum pragma replaces the enumsize pragma. Support for the enumsize 
pragma may be removed in future releases. See Ema more 


information. 


Parameter 


1,2,4 Specifies that enumerations be stored in 1, 2, or 4-byte containers. The sign 
of the container is determined by the range of values in the enumeration. 


Notes: 


1. For this release, if a size is not specified in the pragma, the compiler 
uses the value given in the ENUM compile option. By default this is 
*SMALL, which will use the minimum number of bytes required to 
represent each value of the enumeration. 
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2. If the number of bytes specified in the pragma is less than that required 
to represent each value of the enumeration, the compiler issues a 
warning and sets the size of the enumeration type to the smallest size 
able to represent the enumeration. 


Example 


The size of an enumeration variable is determined by the size of its enumeration 
type. For example: 


#include <stdio.h> 


#pragma enumsize (4) 

enumsize {Small, Big}; /* size of enum is 4 bytes «/ 
int main (void) 

{ 

#pragma enumsize() 

enum length{Long,Short}; /* size of enum is 1 byte */ 


enum size sl; 
enum length 11; 


printf("sizeof sl = %d;sizeof 11 = %d\n", 
sizeof(sl) ,sizeof(11)); 
} 


The output of this example is: 
sizeof sl = 4; size of 11 = 1 
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= 


>>—#—_pragma—exception_handler—(———function_name >—0 7 > 
label »—com_area 


>—,—classI1—,—class2. | ) >< 
'-,—ctl_action 


L -aisgid Tist 


Description 


Enables a user-defined ILE exception handler at the point in the code where the 
#pragma exception_handler is located. 


Any exception handlers enabled by #pragma exception_handler that are not 
disabled using #pragma disable_handler are implicitly disabled at the end of the 
function in which they are enabled. 


Parameters 

function Specifies the name of the function to be used as a user-defined ILE 
exception handler. 

label Specifies the name of the label to be used as a user-defined ILE 


exception handler. The label must be defined within the function 
where the #pragma exception_handler is enabled. When the 
handler gets control, the exception is implicitly handled and 
control resumes at the label defined by the handler in the 
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com_area 


class1, class2 


ctl_action 


invocation containing the #pragma exception_handler directive. 
The call stack is canceled from the newest call to, but not 
including, the call containing the #pragma exception_handler 
directive. The label can be placed anywhere in the statement part 
of the function definition, regardless of the position of the #pragma 
exception_handler. 


Used for the communications area. If no com_area should be 
specified, zero is used as the second parameter of the directive. If a 
com_area is specified on the directive, it must be a variable of one 
of the following data types: integral, float, double, struct, union, 
array, enum, pointer, or packed decimal. The com_area should be 
declared with the volatile qualifier. It cannot be a member of a 
structure or a union. 


Specifies the first four bytes and the last four bytes, respectively, of 
the exception mask. The <except.h> header file describes the 
values that you can use for the class masks. It also contains macro 
definitions for these values. class1 and class2 have to evaluate to 
integer constant expressions after any necessary macro expansions. 
You can monitor for the valid class2 values of: 


° _C2_MH_ESCAPE 

¢* _C2_MH_STATUS 

¢* _C2_MH_NOTIFY, and 

¢ _C2_FUNCTION_CHECK. 


Specifies an integer constant to indicate what action should take 
place for this exception handler. If handler is a function, the default 
value is CTLA INVOKE. If handler is a label, the default value is 
_CTLA_HANDLE. This parameter is optional. 


The following are valid exception control actions that are defined 
in the <except.h> header file: 


#define name Value Action 

_CTLA_INVOKE 1 This control action will cause the function 
named on the directive to be invoked and 
will not handle the exception. If the exception 
is not explicitly handled, processing will 
continue. This is valid for functions only. 

_CTLA_HANDLE 2 The exception is handled and messages are 
logged prior to calling the handler. The 
exception will no longer be active when 
handler gets control. Exception processing 
ends when the exception handler returns. 
This is valid for functions and labels. 

_CTLA_HANDLE_NO MSG 3 The exception is handled but messages are 
not logged prior to calling the handler. The 
exception will no longer be active when 
handler gets control and exception messages 
are not logged. Msg_Ref_Key in the typedef 

INTRPT_Hndlr_Parms_T is set to zero. 

Exception processing ends when the 
exception handler returns. This is valid for 
functions and labels. 
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msgid_list 


#define name Value Action 

_CTLA_IGNORE 131 The exception is handled and messages are 
logged. Control is not passed to the handler 
function named on the directive and 
exception will no longer be active. Execution 
resumes at the instruction immediately 
following the instruction that caused the 
exception. This is valid for functions only. 

_CTLA_IGNORE_NO_MSG 132 The exception is handled and messages are 
not logged. Control is not passed to the 
handler function named on the directive and 
exception will no longer be active. Execution 
resumes at the instruction immediately 
following the instruction that caused the 
exception. This is valid for functions only. 


Specifies an optional string literal that contains the list of message 
identifiers. The exception handler will take effect only when an 
exception occurs whose identifiers matches one of the identifiers 
on the list of message identifiers. The list is a series of 7-character 
message identifiers where the first three characters are the message 
prefix and the last four are the message number. Each message 
identifier is separated by one or more spaces or commas. This 
parameter is optional, but if it is specified, ctl_action must also be 
specified. 


For the exception handler to get control, the selection criteria for 
class1 and class2 must be satisfied. If the msgid_list is specified, the 
exception must also match at least one of the message identifiers in 
the list, based on the following criteria: 


* The message identifier matches the exception exactly. 


* A message identifier, whose two rightmost characters are 00, will 
match any exception identifier that has the same five leftmost 
characters. For example, a message identifier of CPF5100 will 
match any exceptions whose message identifier begins with 
CPF51. 


* A message identifier, whose four rightmost characters are 0000, 
will match any exception identifier that has the same prefix. For 
example, a message identifier of CPF0000 will match any 
exception whose message identifier has the prefix CPF (CPFO000 
to CPF9999), 

* If msgid_list is specified, but the exception that is generated is 
not one specified in the list, the exception handler will not get 
control. 


Notes on Usage 


The macro _C1_ALL, defined in the <except.h> header file, can be used as the 
equivalent of all the valid class1 exception masks. The macro _C2_ALL, defined in 
the <except.h> header file, can be used as the equivalent of all four of the valid 
class2 exception masks. 


You can use the binary OR operator to monitor for different types of messages. For 


example, 


#pragma exception_handler(myhandler, my_comarea, 0, C2 MH ESCAPE | \ 
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_C2_MH_STATUS | _C2_MH_NOTIFY, CTLA_IGNORE, "MCHOQ00") 


will set up an exception monitor for three of the four class2 exception classes that 
can be monitored. 


The compiler issues an error message if any of the following occurs: 

* The directive occurs outside a C function body or inside a C statement. 

* The handler that is named is not a declared function or a defined label. 

* The com_area variable has not been declared or does not have a valid object type. 
* Either of the exception class masks is not a valid integral constant 


* The ctl_action is one of the disallowed values when the handler that is specified 
is a label (.CTLA_INVOKE, _CTLA_IGNORE, _CTLA_IGNORE_NO_MSG). 

* The msgid_list is specified, but the ctl_action is not. 

* A message in the msgid_list is not valid. Message prefixes that are not in 
uppercase are not considered valid. 

* The messages in the string are not separated by a blank or comma. 


“eu 


* The string is not enclosed in or is longer than 4K bytes. 


See the ILE C/C++ Programmer's Guide for examples and more information about 
using the #pragma exception_handler directive. 


hashome 


C++ 


>>—#—pragma—hashome—(—cl Nee C~*~*~“‘“CSOC 
AllInlines 


Description 


Informs the compiler that the specified class has a home module that will be 
specified by #pragma ishome. This class’s virtual function table, along with certain 
inline functions, will not be generated as static. Instead, they will be referenced as 
externals in the compilation unit of the class in which #pragma ishome was 
specified. 


Parameters 

className Specifies the name of a class that requires the above mentioned 
external referencing. className must be a class and it must be 
defined. 

AllInlines specifies that all inline functions from within className should be 


referenced as being external. This argument is case insensitive. 


A warning will be produced if there is a #pragma ishome without a matching 
#pragma hashome. 


See also |“ishome” on page 46 
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implementation 


C++ 


>>—#—_pragma—implementation—(—string_literal—) >< 


Description 


The #pragma implementation directive tells the compiler the name of the file 
containing the function-template definitions that correspond to the template 
declarations in the include file which contains the pragma. This pragma can appear 
anywhere that a declaration is allowed. It is used when organizing your program 
for the efficient or automatic generation of template functions. 


import 


G++ 
>>—#—pragma—import > 
»>—(—identifier—, 7 »—"—module—"—) >< 
‘—"—export_name—" 
Description 


Imports a function or a variable from a shared library using a name different from 
the one that it has in the shared library. 
Parameters 


identifer Specifies the name you use in your source to refer to the function 
or variable. If identifier is the name of an overloaded function or a 
member function, there is a risk that the pragma will override 
compiler-generated names. This will create problems during 
linking. 


export_name Specifies the name of the function or variable in the shared library. 
module Specifies the name of the shared library containing the identifier. 
Notes on Usage 


Both identifier and export_name must be defined only once in each compilation unit. 


The information provided by #pragma import is used at load time to locate the 
imported identifier. If an identifier is specified in more than one #pragma import, 
all instances of the pragma must have the same export_name and module. If the 
export name or module name are different, an error will occur. 


Example 


The following imports "Joe" from the "TeamList”: 
#pragma import(player, "Joe", "TeamList") 
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info 


C++ 


>>—#—pragma 


Description 


info—( all ) 
none 
restore 


v 


nogroup ,H 
‘group 


This pragma can be used to control which diagnostic messages are produced by 


the compiler. 


Parameters 
all 

none 
restore 


nogroup 


group 


Generates all diagnostic messages while this pragma is in effect. 
Turns off all diagnostic messages while this pragma is in effect. 
Restores the previous setting of pragma info. 


Suppresses all diagnostic messages associated with a specified 


diagnostic group. To turn off a specific group of messages, prepend 


the group name with "no”. For example, nogen will suppress 
CHECKOUT messages. Valid group names are listed below. 


Generates all diagnostic messages associated with the specified 
diagnostic group. Valid group names are: 


lan Display information about the effects of the language level 

gnr Generate messages if the compiler creates temporary 
variables 

cls Display information about class use 

eff Warn about statements with no effect 


cnd —_ Warn about possible redundancies or problems in 
conditional expressions 


rea Warn about unreachable statements 

par List the function parameters that are not used. 

por List the non-portable usage of the C/C++ language. 
trd Warn about the possible truncation or loss of data 
use Check for unused auto or static variables 

use Check for unused auto or static variables 


gen _ List the general CHECKOUT messages. 
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inline 


p>—#—pragma—in] ine—(—function_name—) >< 


Description 


The #pragma inline directive specifies that function_name is to be inlined. The 
pragma can appear anywhere in the source, but must be at file scope. The pragma 
has no effect if the INLINE(*ON) parameter is not specified on the Create Module 
or Create Bound Program commands. If #pragma inline is specified for a function, 
the inliner will force the function specified to be inlined on every call. The function 
will be inlined in both selective (*(NOAUTO) and automatic (*AUTO) INLINE 
mode. 


Inlining replaces function calls with the actual code of the function. It reduces 
function call overhead, and exposes more code to the optimizer, allowing more 
opportunities for optimization. 


Notes on Usage 
* Inlining takes place only if compiler optimization is set to level 30 or higher. 


* Directly recursive functions will not be inlined. Indirectly recursive functions 
will be inlined until direct recursion is encountered. 

* Functions calls with variable argument lists will not be inlined if arguments are 
encountered in the variable portion of the argument list. 

* Ifa function is called through a function pointer, then inlining will not occur. 

* The pragma inline directive will be ignored if function_name is not defined in 
the same compilation unit that contains the pragma. 

¢ A function’s definition will be discarded if the function is static, if it has not had 
its address taken and if it has been inlined everywhere it is called. This action 


can decrease the size of the module and program object where the function is 
used. 


See the "Function Call Performance” appendix of the ILE C/C++ Programmer’s Guide 
for more information on function inlining. 


ishome 


C++ 


>>—#—pragma—i shome—(—className—) >< 


Description 


Informs the compiler that the specified class’s home module is the current 
compilation unit. The home module is where items, such as the virtual function 
table, are stored. If an item is referenced from outside of the compilation unit, it 
will not be generated outside its home. The advantage of this is the minimization 
of code. 
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Parameters 
className Specifies the literal name of the class whose home will be the 


current compilation unit. 


A warning will be produced if there is a #pragma ishome without a matching 
#pragma hashome. 


See also |“hashome” on page 43 


isolated_call 


C++ 


>>—i#—pragma—isolated_cal]l—=—function >< 


Description 


Lists a function that does not have or rely on side effects, other than those implied 
by its parameters. 


Parameters 


function Specifies a primary expression that can be an identifier, operator 
function, conversion function, or qualified name. An identifier 
must be of type function or a typedef of function. If the name 
refers to an overloaded function, all variants of that function are 
marked as isolated calls. 


Notes on Usage 


The pragma informs the compiler that the function listed does not have or rely on 
side effects, other than those implied by its parameters. Functions are considered to 
have or rely on side effects if they: 


* Access a volatile object 

* Modify an external object 

* Modify a static object 

* Modify a file 

* Access a file that is modified by another process or thread 

* Allocate a dynamic object, unless it is released before returning 

* Release a dynamic object, unless it was allocated during the same invocation 
* Change system state, such as rounding mode or exception handling 

* Call a function that does any of the above 


Essentially, any change in the state of the runtime environment is considered a side 
effect. Modifying function arguments passed by pointer or by reference is the only 
side effect that is allowed Functions with other side effects can give incorrect 
results when listed in #pragma isolated_call directives. 


Marking a function as isolated_call indicates to the optimizer that external and 
static variables cannot be changed by the called function and that pessimistic 
references to storage can be deleted from the calling function where appropriate. 
Instructions can be reordered with more freedom, resulting in fewer pipeline 
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delays and faster execution in the processor. Multiple calls to the same function 
with identical parameters can be combined, calls can be deleted if their results are 
not needed, and the order of calls can be changed. 


The function specified is permitted to examine non-volatile external objects and 
return a result that depends on the non-volatile state of the runtime environment. 
The function can also modify the storage pointed to by any pointer arguments 
passed to the function, that is, calls by reference. Do not specify a function that 
calls itself or relies on local static storage. Listing such functions in the #pragma 
isolated_call directive can give unpredictable results. 


linkage 


> c | 

>>— i#—pragma—] inkage—( ee | »—0S 7] ) >< 
'_typedef_name '_,—nowiden 

Description 


Identfies a given function or function typedef as being an external program subject 
to OS/400 parameter passing conventions. 


This pragma allows calls only to external programs. For information on making 
calls to bound procedures, see pragma : 
Parameter 


program_name Specifies the name of an external program. The external name must 
be specified in uppercase characters and be no longer than 10 
characters in length, unless the #pragma map directive is specified 
to meet OS/400 program naming conventions. However, if the 
name specified in #pragma map is too long, it will be truncated to 
255 characters during #pragma linkage processing. 


typedef_name Specifies a typedef affected by this pragma. 


OSs Specifies that the external program is called using OS/400 calling 
conventions. 

nowiden If specified, arguments are not widened before they are copied and 
passed. 


Notes on Usage 


This pragma lets an iSeries program call an external program. The external 
program can be written in any language. 


The pragma can be applied to functions, function types, and function pointer 
types. If it is applied to a function typedef, the effect of the pragma also applies to 
all functions and new typedefs declared using that original typedef. 


This directive can appear either before or after the program name (or type) is 
declared. However, the program cannot have been called, nor a type been used in 
a declaration, before the pragma directive. 
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The function or function pointer can only return either an int or a void. 


Arguments on the call are passed according to the following OS/400 
argument-passing conventions: 


* Non-address arguments are copied to temporary locations, widened (unless 
nowiden has been specified) and the address of the copy is passed to the called 
program 


* Address arguments are passed directly to the called program. 


The compiler issues a warning message and ignores the #pragma linkage directive 
if: 


* The program is declared with a return type other than int or void. 
* The function contains more than 256 parameters. 


* Another pragma linkage directive has already been specified for the function or 
function type. 


* The function has been defined in the current compilation unit. 


* The specified function has already been called, or the type already used in a 
declaration. 


* #pragma argopt or #pragma argument has already been specified for the named 
function or type. 


* The object named in the pragma directive is not a function or function type. 


* The name of the object specified in the pragma directive must not exceed 10 
characters, or the name will be truncated. 


map 
= 
>>—#—pragma—map—(—name1—,—” —name2—" —) >< 
Description 
Specifies that the compiler is to replace the external symbol (that is used in your C 
source) name1 with the external symbol name2. Case significance is preserved only 
for those systems, that support case distinction for external symbols. 
The #pragma map directive supports library-qualified external program names. See 
“linkage” on page 48] for more information. 

mapinc 


>>—#—pragma—mapinc—(—"include_name" —, > 
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*LIBL/ 


file_name—( *ALL ) 
| scurtie/_ : 


_Y_format_name— 


>—,—"options” 


| brary nianer= 


C Z 

2 : J ' > 
P 1BYTE_CHAR 

Ps aiaal 


Description 


_,—"union_type_name" 


T? >< 


\_,—"prefix_name" J 


Indicates that external file descriptions (DDS) are to be included in a module. The 
directive identifies the file and DDS record formats, and provides information on 
the fields to be included. This pragma, along with its associated include directive, 
causes the compiler to automatically generate typedefs from the record formats 
that are specified in the external file descriptions. 


Parameters 


include_name 


library_name 


file_name 


format_name 


options 
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This is the name that you refer to on the #include directive in the 
source program. 


This is the name of the library that contains the externally 
described file 


This is the name of the externally described file. 


This is a required parameter which indicates the DDS record 
format that is to be included in your program. You can include 
more than one record format (format1 format2), or all the formats 
in a file (*ALL). 


The possible options are: 


input Fields declared as either INPUT or BOTH in the 
DDS are included in the typedef structure. 
Response indicators are included in the input 
structure when the keyword INDARA is not 
specified in the external file description (DDS 
source) for device files. 


output Fields declared as either OUTPUT or BOTH in 
DDS are included in the typedef structure. Option 
indicators are included in the output structure 
when the keyword INDARA is not specified in the 
external file description (DDS source) for device 
files. 


both Fields declared as INPUT, OUTPUT, or BOTH in 
DDS are included in the typedef structure. Option 
and response indicators are included in both 


structures when the keyword INDARA is not 
specified in the external file description (DDS 
source) for device files. 


key Fields that are declared as keys in the external file 
description are included. This option is only valid 
for database files and DDM files. 


indicators A separate 99-byte structure for indicators is 
created when the indicator option is specified. This 
option is only valid for device files. 


Iname This option allows the use of file names of up to 
128 characters in length. If the file name has more 
than 10 characters then the name will be converted 
to an associated short name. The short name will 
be used to extract the external file definition. When 
the file has a short name of 10 characters or less 
the name is not converted to an associated short 
name. Record field names up to 30 characters in 
length will be generated in the typedefs by the 
compiler. 


Ivichk A typedef of an array of struct is generated (type 
name _LVLCHK_T) for the level check information. 
A pointer to an object of type _LVLCHK_T is also 
generated and is initialized with the level check 
information (format name and level identifier). 


nullflds If there is at least one null-capable field in the 
record format of the DDS, a null map typedef is 
generated containing a character field for every 
field in the format. With this typedef, the user can 
specify which fields are to be considered null (set 
value of each null field to 1, otherwise set to zero). 
Also, if the key option is used along with option 
nullflds, and there is at least one null-capable key 
field in the format, an additional typedef is 
generated containing a character field for every key 
field in the format. 


For physical and logical files you can specify input, both, key, 
lvichk, and nullfids. For device files you can specify input, 
output, both, indicator, and lvlchk. 


The data type can be one or more of the following and must be 
separated by spaces. 


d Packed decimal data type. 
p Packed fields from DDS are declared as character fields. 
Z Zoned fields from DDS are declared as character fields. 


This is the default because the compiler does not have a 
zoned data type. 


P Packed structure is generated. 


1BYTE_CHAR 
Generates a single byte character field for one byte 
characters that are defined in DDS. 
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margins 


mo 


Default values of d and z are used. 


union_type_name 
A union definition of the included type definitions is created with 
the name union_type_name_t. This parameter is optional. 


prefix_name Specifies the first part of the generated typedef structure name. If 
the prefix is not specified, the library and file_name are used. 


Notes on Usage 
See Using Externally Described Files in Your ILE C/C++ Program in ILE C/C++ 


Programmer's Guide for more information about using the #pragma mapinc 
directive with externally described files. 


>>—i#—pragma—margins—(—left margin—,——right margin ) >< 


L_x. 


Description 


Specifies the left and right margins to be used as the first and last column, 
respectively, when scanning the records of the source member where the #pragma 
directive occurs. 


The margin setting applies only to the source member in which it is located and 
has no effect on any source members named on include directives in the member. 


Parameters 


left margin Must be a number greater than zero but less than 32 754. The left 
margin should be less than the right margin. 


right margin Must be a number greater than zero but less than 32 754, or an 
asterisk (*). The right margin should be greater than the left margin. 
The compiler scans between the left margin and the right margin. 
The compiler scans from the left margin specified to the end of the 
input record, if an asterisk is specified as the value of right margin. 


Notes on Usage 


The #pragma margins directive takes effect on the line following the directive and 
remains in effect until another #pragma margins or nomargins directive is 
encountered or the end of the source member is reached. 


The #pragma margins and #pragma sequence directives can be used together. If 
these two #pragma directives reserve the same columns, the #pragma sequence 
directive has priority, and the columns are reserved for sequence numbers. 


For example, if the #pragma margins directive specifies margins of 1 and 20, and 
the #pragma sequence directive specifies columns 15 to 25 for sequence numbers, 
the margins in effect are 1 and 14, and the columns reserved for sequence numbers 
are 15 to 25. 
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If the margins specified are not in the supported range or the margins contain 
non-numeric values, a warning message is issued during compilation and the 
directive is ignored. 


See also pragmas|“nomargins” on page 54]and |“sequence” on page 64 


namemangling 
C++ 
ore 
>>—#—pragma—namemang] ing—( compat >< 
‘—num_chars 
Description 
Sets the maximum length for external symbol names generated from C++ source 
code. 
Parameters 
ansi The name mangling scheme complies with the C++ standard. If 
you specify ansi but do not specify a size, the default maximum is 
64000 characters. 
compat The name mangling scheme is the same as in earlier versions of 
the compiler. The default maximum is 255 characters. Use this 
scheme for compatability with link modules created with earlier 
versions of the compiler. 
function Optionally specifies a maximim length for external symbol names 
generated from C++ source code. 
noargvO 


>>—#—pragma—noargv0 >< 


Description 

Specifies that the source program does not make use of argv[0]. This pragma can 
improve performance of applications that have a large number of small C 
programs, or a small program that is called many times. 


Notes on Usage 


The #pragma noargv0 must appear in the compilation unit where the main() 
function is defined, otherwise it is ignored. 
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argv[0] will be NULL when the noargv0 pragma directive is in effect. Other 
arguments in the argument vector will not be affected by this directive. If the 
#pragma noargvO directive is not specified, argv[0] will contain the name of the 
program that is currently running. 


noinline (function) 


>>—#—pragma—noinl ine—(—function_name—) >< 


Description 


Specifies that a function will not be inlined. The settings on the INLINE parameter 
of the Create Module or Create Bound Program commands will be ignored for this 
function_name. 


Notes on Usage 

The first pragma specified will be the one that is used. If #pragma inline is 
specified for a function after #pragma noinline has been specified for it, a warning 
will be issued to indicate that #pragma noinline has already been specified for that 
function. 


The #pragma noinline directive can only occur at file scope. 


The pragma will be ignored, and a warning that is issued if it is not found at file 
scope. 


nomargins 


>>—#—pragma—nomarg ins AAA a 


Description 

Specifies that the entire input record is to be scanned for input. 

Notes on Usage 

The #pragma nomargins directive takes effect on the line following the directive 


and remains in effect until a #pragma margins directive is encountered or the end 
of the source member is reached. 


See also pragma|’margins” on page 52 
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nosequence 


>>—#—pragma—nosequence >< 


Description 

Specifies that the input record does not contain sequence numbers. 

Notes on Usage 

The #pragma nosequence directive takes effect on the line following the directive 


and remains in effect until a #pragma sequence directive is encountered or the end 
of the source member is reached. 


See also pragma|“sequence” on page 64 


nosigtrunc 


>>—#—pragma—nosigtrunc >< 


Description 


Specifies that no exception is generated at run time when overflow occurs with 
packed decimals in arithmetic operations, assignments, casting, initialization, or 
function calls. This directive suppresses the signal that is raised in packed 
decimaloverflow. The #pragma nosigtrunc directive can only occur at filescope. A 
warning message will be issued if the #pragma nosigtrunc directive is encountered 
at function, block or function prototype scope, and the directive will be ignored. 


Notes on Usage 


This #pragma directive has file scope and must be placed outside a function 
definition; otherwise it is ignored. A warning message may still be issued during 
compilation for some packed decimal operations if overflow is likely to occur. See 
ILE C/C++ Programmer’s Guide for more information about packed decimalerrors. 


object_model 


C++ 
compat— 
>>—#—pragma—object_model—( ) >< 
ibm 
pop 
Description 
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Sets the type of object model used when compiling an object. 


Parameters 
compat Uses an object model compatible with previous versions of the 
compiler on program code following the pragma statment. This 
object model remains in effect until another pragma object_model 
statement is reached. 
ibm Uses the current object model on program code following the 
pragma statment. This object model remains in effect until another 
pragma object_model statement is reached. 
pop Selects the previously-used object model. 
pack 
= 
>>—#—pragma—pack—( ) >< 
1 
2 
4 
8 
16 
default 
system 
pop 
“_reset— 
Description 


The #pragma pack directive specifies the alignment rules to use for the members of 
the structure, union, or (C++ only) class that follows it. In C++, packing is 
performed on declarations or types. This is different from C, where packing is also 
performed on definitions. 


You can also use the PACKSTRUCT option with the Create Module or Create 
Bound Program commands to cause packing to be performed along specified 
boundaries. See|“PACKSTRUCT” on page 100) for more information. 
Parameters 


1,2,4,8,16 Structures and unions are packed along the specified byte 


boundaries. 

default Selects the alignment rules specified by compiler option 
PACKSTRUCT. 

system Selects the default iSeries alignment rules. 

pop, reset Selects the alignment rules previously in effect, and discards the 


current rules. This is the same as specifying #pragma pack ( ). 
In the examples that follow, the words struct or union can be used in place of class. 
The #pragma pack settings are stack based. All pack values are pushed onto a 


stack as the user’s source code is parsed. The value on the top of that stack is the 
current packing value. When a #pragma pack (reset), #pragma pack(pop), or 
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#pragma pack() directive is given, the top of the stack is popped and the next 
element in the stack becomes the new packing value. If the stack is empty, the 
value of the PACKSTRUCT compiler option, if specified, is used. If not otherwise 
specified, the default setting of NATURAL alignment is used. 


The setting of the PACKSTRUCT compiler option is overridden by the #pragma 
pack directive, but always remains on the bottom of the stack. The keyword 
_Packed has the highest precedence with respect to packing options, and cannot be 
overridden by the #pragma pack directive or the PACKSTRUCT compiler option. 


By default, all members use their natural alignment. Members cannot be aligned 
on values greater than their natural alignment. Char types can only be aligned 
along 1-byte boundaries. Short types can only be aligned along 1 or 2-byte 
boundaries, and int types can be aligned along on 1, 2, or 4-byte boundaries. 


All 16-byte pointers will be aligned on a 16-byte boundary. _Packed, 
PACKSTRUCT, and #pragma pack cannot alter this. 8-Byte teraspace pointers may 
have any alignment, although 8-byte alignment is preferred. 


Related Operators and Specifiers 


__align Specifier 

The __align specifier lets you specify the alignment of a Data Item or a ILE C/C++ 
aggregate (such as a struct or union for ILE C, as well as classes for ILE C++). 
However, __align does not affect the alignment of members within an aggregate, 
only the alignment of the aggregate as a whole. Also, because of restrictions for 
certain members of an aggregate, such as 16-byte pointers, the alignment of an 
aggregate is not guaranteed to be aligned in memory on the boundary specified by 
__align. For example, an aggregate that has a 16-byte pointer as its only member 
cannot have any other alignment other than 16-byte alignment because all 16-byte 
pointers *must* be aligned on the 16-byte boundary. 


»>—declarator—_ align 


—identifer—; >< 


p>—struct_specifier—_ align >< 


identifer—struct_declaration_l ist] 


You can also use the __align specifier to explicitly specify alignment when 
declaring or defining data items, as shown in some of the examples that follow. 


The __align specifier: 


* can only be used with declarations of first-level variables and aggregate 
definitions. It ignores parameters and automatics. 


* cannot be used on individual elements within an aggregate definition, but it can 
be used on an aggregate definition nested within another aggregate definition. 


* cannot be used in the following situations: 
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— Individual elements within an aggregate definition. 

— Variables declared with incomplete type. 

— Aggregates declared without definition. 

— Individual elements of an array. 

— Other types of declarations or definitions, such as function and enum. 


— Where the size of variable alignment is smaller than the size of type 
alignment. 


__ Packed Specifier 

_Packed can be associated with struct, union, and in C++, class definitions. It has 
the same effect as #pragma pack(1). The following are examples of legal and illegal 
usages of _Packed. In these examples, the keywords struct, union, and class can be 


used interchangeably. 
_Packed class SomeClass { /* ... */ }3 


// OK 


typedef Packed union AnotherClass {} PUnion; // OK 


typedef Packed struct {} PAnonStruct; 
_Packed SomeClass someObject; 


_Packed struct SomeStruct { }; 
_Packed union SomeUnion { }; 


// Tllegal, struct must be named 

// Illegal, specifier _Packed must 

// be associated with class definition. 
// OK 

// OK 


__alignof Operator 


unary-expression: 
__alignof unary-expression 
__alignof ( type-name ) 


The __alignof operator returns the alignment of its operand, which may be an 
expression or the parenthesized name of a type. The alignment of the operand 
would be determined according to the alignment rule on a specific platform. 
However, it should not be applied to an expression that has function type or an 
incomplete type, to the parenthesized name of such a type, or to an expression that 
designates a bit-field member. The type of the result of this operator should be 
size_t. 


Examples 


In the examples that follow, the words union and class could be used in place of the 
word struct. 


1. Popping the #pragma pack Stack 


Specifying #pragma pack (pop), #pragma pack (reset), or #pragma pack() pops 
the stack by one and resets the alignment requirements to the state that was 
active before the previous #pragma pack was seen. For example, 


// Default alignment requirements used 


#pragma pack (4) 
struct A { }3 
#pragma pack (2) 
struct B { }3 
struct C { }3 
#pragma pack (reset) 
struct D { }3 
#pragma pack () 
struct E { }3 
#pragma pack (pop) 
struct F { }3 
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When struct A is mapped, its members are aligned according to #pragma 
pack(4). When struct B and struct C are mapped, their members are aligned 
according to pragma pack(2). 


The #pragma pack (reset) pops the alignment requirements specified by 
#pragma pack(2) and resets the alignment requirements as specified by 


#pragma pack(4). 


When struct D is mapped, its members are aligned according to pragma 
pack(4). The #pragma pack () pops the alignment requirements specified by 
#pragma pack(4) and resets the alignment requirements to the default values 
used at the beginning of the file. 


When struct E is mapped, its members are aligned as specified by the default 
alignment requirements (specified on the command line) active at the beginning 
of the file. 


The #pragma pack (pop) has the same affect as the previous #pragma pack 
directives in that it pops the top value from the pack stack. However, the 
default pack value, as specified in the PACKSTRUCT compiler option, cannot 
be removed from the pack stack. That default value is used to align struct F. 


. _align & #pragma pack 


__align(16) struct S {int i;}; /* sizeof(struct S) == 16 */ 
struct S1 (struct S s; int a3}; /* sizeof(struct $1) == 32 */ 
#pragma pack(2) 
struct S2 {struct S s; int a;} s2; /* sizeof(struct $2) == 32 +*/ 
/* offsetof(S2, s1) 
/* offsetof(S2, a) = 


== 0 */ 

= 16 */ 
#pragma pack 

In this example, since the data types are by default packed along boundaries 
smaller than those specified by #pragma pack (8), they are still aligned along 
the smaller boundary (alignof(S2) = 4). 


#pragma pack(2) 


struct S$ { /* sizeof(struct S$) == 48 +*/ 
char a; /* offsetof(S, a) == 0 */ 
int» b; /* offsetof(S, b) == 16 */ 
char c; /* offsetof(S, c) == 32 */ 
short d; /* offsetof(S, d) == 34 */ 
}S; /* alignof(S) == 16 */ 


char a; /* offsetof(S1, a) == 0 */ 
int b; /* offsetof(Sl, b) == 2 */ 
char c; /* offsetof(S1, c) == 6 */ 
short d; /* offsetof(S1l, d) == */ 
}S1; /* alignof(S1) == */ 


struct $1 { /* sizeof(struct $1) == 10 */ 


#pragma pack(8) 
struct S2 { /* sizeof(struct $2) == 12 */ 


char a; /* offsetof(S2, a) == */ 
int b; /* offsetof(S2, b) == */ 
char c; /* offsetof(S2, c) == */ 
short d; /* offsetof(S2, d) == 10 */ 
}S2; /* alignof(S2) == */ 


. PACKSTRUCT Compiler Option 
If the following is compiled with PACK STRUCTURE set to 2: 
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struct S1 { /* sizeof(struct $1) = 
char a; /* offsetof(Sl, a) == 
int b; /* offsetof(S1, b) == 2 */ 
char c; /* offsetof(S1, c) == 6 */ 
short d; /* offsetof(Sl, d) == 8 */ 


}S1; /* alignof(S1) == */ 
5. #pragma pack 
If the following is compiled with PACK STRUCTURE set to 4: 


#pragma pack(1) 
struct A { // this structure is packed along 1-byte boundaries 
char al; 
int a2; 
} 
#pragma pack(2) 
struct B { // this class is packed along 2-byte boundaries 
int bl; 
float b2; 
float b3; 
}s 


#pragma pack(pop) // this brings pack back to 1-byte boundaries 
struct C { 

int cl; 

char c2; 

short c33 

}; 
#pragma pack(pop) // this brings pack back to the compile option, 
struct D { // 4-byte boundaries 


int dl; 
char d2; 
}; 
6. __align 
int _align(16) varA; /* varA is aligned on a 16-byte boundary */ 
7. __Packed 
struct A { /* sizeof(A) == 24 */ 
int a; /* offsetof(A, a) == */ 
long long b; /* offsetof(A, b) == */ 


short c; /* offsetof(A, c) == 16 */ 
char d; /* offsetof(A, d) == 18 */ 
}3 


_Packed struct B { /* sizeof(B) == 15 */ 
int a; /* offsetof(B, a) == */ 
long long b; /* offsetof(B, b) == */ 


short c; /* offsetof(B, c) == 12 */ 

char d; /* offsetof(B, d) == 14 */ 
bs 
Layout of struct A, where * = padding: 
Jalalala]*|*|*|*|b|b|b|b]b] bb] b]c|c|d|*|*|*|*|+| 


Layout of struct B, where * = padding: 
|alalala|b|b|b|b|b|b|b|b]c|c|a| 
8. __alignof 


struct A { 
char a3 
short b; 
}; 


struct B { 
char a3 
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long b; 
} varb; 


int var; 


In the code sample above: 
* __alignof(struct A) = 2 
* __alignof(struct B) = 4 
* __alignof(var) = 4 

¢ __alignof(varb.a) = 1 


__align(16) struct A { 
int a; 
int b; 

}; 


#pragma pack(1) 

struct B { 
long a; 
long b; 

}s 


struct C { 
struct { 
short a; 
int b; 
} varb; 
} var; 


In the code sample above: 
* __alignof(struct A) = 16 
* __alignof(struct B) = 4 

* __alignof(var) = 4 

* __alignof(var.varb.a) = 4 


page 


> 


>>—#—pragma—page— E11 
n 


Description 


Skips n pages of the generated source listing. If n is not specified, the next page is 


started. 


pagesize 


- c 


>>—#—pragma—pagesize 


( 


ee 
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Description 


Sets the number of lines per page to n for the generated source listing. The 
pagesize pragma may not affect the option listing page (that is sometimes called 
the Prolog). 


pointer 


= 


>>—#—pragma—pointer—(—typedef_name—,—pointer_type—) >< 


Description 


Allows the use of iSeries pointer types: 

* space pointer 

* system pointer 

* invocation pointer 

* label pointer 

* suspend pointer 

* open pointer 

A variable that is declared with a typedef that is named in the #pragma pointer 
directive has the pointer type associated with typedef_name in the directive. The 
<pointer.h> header file contains typedefs and #pragma directives for these pointer 


types. Including this header file in your source code allows you to use these 
typedefs directly for declaring pointer variables of these types. 


Parameters 


pointer_type which can be one of: 


SPCPTR Space pointer 
OPENPTR Open pointer 
SYSPTR System pointer 
INVPTR Invocation pointer 
LBLPTR Label code pointer 
SUSPENDPTR 


Suspend pointer 
Notes on Usage 


The compiler issues a warning and ignores the #pragma pointer directive if any of 
the following errors occur: 


* The pointer type that is named in the directive is not one of SPCPTR, SYSPTR, 
INVPTR, LBLPTR, SUSPENDPTR, or OPENPTR. 


* The typedef named is not declared before the #pragma pointer directive. 


* The identifier that is named as the first parameter of the directive is not a 
typedef. 


* The typedef named is not a typedef of a void pointer. 
* The typedef named is used in a declaration before the #pragma pointer directive. 
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priority 


The typedef named must be defined at file scope. 


See ILE C/C++ Programmer's Guide for more information about using iSeries 
pointers. 


C++ 


>>—#—pragma—priority—(—n—) >< 


Description 


The #pragma priority directive specifies the order in which static objects are to be 
initialized at run time. 


The value n is an integer literal in the range of INT_MIN to INT_MAX. The 
default value is 0. A negative value indicates a higher priority; a positive value 
indicates a lower priority. 


The first 1024 priorities (INT_MIN to INT_MIN + 1023) are reserved for use by 
the compiler and its libraries. The #pragma priority can appear anywhere in the 
source file many times. However, the priority of each pragma must be greater than 
the previous pragma’s priority. This is necessary to ensure that the runtime static 
initialization occurs in the declaration order. 


Example 
//File one called First.C 


#pragma priority (1000) 

class A { public: int a; A() {return;} } a; 
#pragma priority (3000) 

class C { public: int c; C() {return;} } c; 
class B { public: int b; B() {return;} }; 


extern B b; 

main() 

{ 
a.a=03 
b.b=0; 
c.c=0; 


//File two called Second.C 
#pragma priority (2000) 
class B { public: int b; B() {return;} } b; 


In this example, the execution sequence of the runtime static initialization is: 
1. Static initialization with priority 1000 from file First.C 

2. Static initialization with priority 2000 from file Second.C 

3. Static initialization with priority 3000 from file First.C 
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sequence 


>>—#—_pragma—sequence—(—left_column—,—right_column ) >< 
Lx. 
Description 


Specifies the columns of the input record that are to contain sequence numbers. 
The column setting applies only to the source setting in which it is located and has 
no effect on any source members named on include directives in the member. 


Parameters 


left column Must be greater than zero but less than 32 754. The left column 
should be less than the right column. 


right column Must be greater than zero but less than 32 754. The right column 
should be greater than or equal to the left column. An asterisk (*) 
that is specified as the right column value indicates that sequence 
numbers are contained between left column and the end of the 
input record. 


Notes on Usage 


The #pragma sequence directive takes effect on the line following the directive. It 
remains in effect until another #pragma sequence or nosequence directive is 
encountered or the end of the source member is reached. 


The #pragma margins and sequence directives can be used together. If these two 
#pragma directives reserve the same columns, the #pragma sequence directive has 
priority, and the columns are reserved for sequence numbers. 


For example, if the #pragma margins directive specifies margins of 1 and 20 and 
the #pragma sequence directive specifies columns 15 to 25 for sequence numbers, 
the margins in effect are 1 and 14, and the columns reserved for sequence numbers 
are 15 to 25. 


If the margins specified are not in the supported range or the margins contain 
non-numeric values, a warning message is issued during compilation and the 
directive is ignored. 


See also pragmas|“nosequence” on page 55|and|“margins” on page 52 


skip 


>>—#—pragma—ski p—( 7] ) >< 
Ln 


Description 
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Skips the next n lines of the generated source listing. The value of n must be a 
positive integer less than 255. If n is omitted, one line is skipped. 


strings 


weak 


c+ 


>>—#—pragma—strings—( | ) >< 
“writeable 


Description 
Specifies that the compiler may place strings into read-only memory or must place 
strings into writeable memory. Strings are writeable by default. This pragma must 


appear before any C or C++ code in a file. 


Note: This pragma will override the *STRDONLY option on the Create Module or 
Create Bound Program commands. 


C++ 


>>—#—pragma—weak—(—identifier ) >< 


'_identifier2— 


Description 


Identifies an identifier to the compiler as being a weak global symbol. 


Parameters 

identifier Specifies the name of an identifier considered to be a weak global 
symbol. 

identifier2 If identifer2 is specified, then identifier is considered to be a weak 


global symbol whose value is the same as identifier2. For this 
pragma to have effect, identifier2 must be defined in the same 
compilation unit. 


This pragma can appear anywhere in a program, and identifies a specified 
identifier as being a weak global symbol. Identifier should not be defined, but it 
may be declared. If it is declared, and identifier2 is specified, identifier must be of a 
type compatible to that of identifier2. 


Example. 
#pragma weak funcl = func2 
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Chapter 4. Control Language Commands 


This chapter discusses the Control Language (CL) commands that are used with 
the ILE C/C++ compiler. Syntax diagrams and parameter description tables are 
provided. 


This table describes the CL commands that are used with the ILE C/C++ compiler. 


Table 1. Control Language Commands 


Action Command Description 
Create C Module CRTCMOD Creates a module object (*MODULE) 
Gieaioe er idle CRTCPPMOD based on the source you provide. 


Create Bound C Program CRTIBNDC Creates a program object (*PGM) based 
on the source you provide. 


Create Bound C++ Program |CRTBNDCPP 


CL commands and their parameters can be entered in either uppercase or 
lowercase. In this manual, they are always shown in uppercase. For example: 
CRTCPPMOD MODULE(ABC/HELLO) SRCSTMF('/home/usr/hello.C') OPTIMIZE(40) 


ILE C/C++ language statements must be entered exactly as shown. For example, 
fopen, _Ropen, because the ILE C/C++ compiler is case-sensitive. 


Variables appear in lowercase italic letters. For example, file-name within language 
statements. They represent user-supplied names or values. 


Language statements may contain punctuation marks, parentheses, arithmetic 
operators, or other such symbols. You must enter them exactly as shown in the 


syntax diagram. 


You can also invoke the compiler and its options through the QShell command line 
environment. For more information on QShell command and option formats, see 


Chapter 5, “Using the ixlc Command to Invoke the C/C++ Compiler” on page 109 


Control Language Command Syntax 


The syntax diagrams in this section show all parameters and options of the 
CRTCMOD, CRTCPPMOD, CRTBNDC, and CRTBNDCPP commands, and the 
default values for each option. In most cases the keywords are identical for any of 


the commands. Differences are noted where they exist. For detailed descriptions of 
each option, see |“Control Language Command Options” on page 73 


Syntax Diagram 


(1) *CURLIB/ 
>>. CRTCMOD MODULE ( module-name—) > 
2 _library-name/— 
L_CRTCPPMOD 
(1) —*CURLIB/ 
CRTBNDC PGM( program-name—) 
2 _library-name/— 
-_CRTBNDCPP. 
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SRCFILE( 


(2) (4) 


(5) 


*LIBL/ 


*CURLIB/ source-file-name— 
_library-name/— 
>. > 
(7) L_sRcsTMF( ) 
*PGM | path-name—! 
(6) 
*MODULE. 
SRCMBR( ) 
_member-name— 
>. > 
-—*SRCMBRTXT | 
TEXT ( *BLANK. ) 
__'__description—'— 
>. > 
L —*NONE | 
OUTPUT ( *PRINT- ) 
filename *BLANK: —*BLANK. 
TITLE title SUBTITLE: subenies! 
>- > 
OPTION (— OPTION Details ) CHECKOUT (— CHECKOUT Details = 
>- > 
10 INLINE ( | INLINE Details =s 
_OPTIMIZE( 20 ) 
30 
Lag 
>- > 
(6) —*NOKEEPILDTA— *NONE 
L_MODCRTOPT ( ) DBGVIEW( *ALL ) 
L_* KEEPI LDTA—— * STMT 
* SOURCE 
Lx*LIST— 
>. 
* NONE: [ —* EXTENDED: | 
LANGLVL ( *ANSI ) 
(2) 
DEFINE ( '—name—' ) L*LEGACY: 
'—name—=—value—' 
>- 
(4) 
—*IFS6410: 
(3) (1) 
L-*NOIFSIO: *NOASYNCSIGNAL 
_SYSIFCOPT( ) 
L*IFS10 (1) 
L_*ASYNCSIGNAL. 
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*LOCALE 
(1) 
_LOCALETYPE (—4—*CLD 


*LOCALEUCS2— 


—0 | 
FLAG(—+-10-+~) 
) L-20 
L30 


*NOMAX 30 
0 32767 0 


MSGLMT ( 


| 
) 


*YES | 
nol) 


L_REPLACE ( 


(7) ee 


USRPRF ( 


*OWNER——) 


-—* LIBCRTAUT: 
* CHANGE 


AUT ( 


Jk 


>-*CURRENT 
*PRV 


GTRLS ( 


*USE 
*ALL 


t-* EXCLUDE 


__quthorization-list-name— 


_release-level— 


*PEP 


ENBPFRCOL ( 


*FULL 


eee 


*ALLPRC 
*NONLEAF: 


-—*SETFPCA 


*NOSTRDONLY— 


PFROPT ( 


) 


| *NOCOL 
PRFDTA(—+—*COL 


'—*NOSETFPCA— 


'—* STRDONLY—— 


«NO: 


__TERASPACE ( *YES 


--*NOTSIFC— 


L_«TSIFC— 


--*SNGLVL 
* TERASPACE 
—* INHERIT, 


LSTGMDL( 


Al ae: 


*P128 il 
*LLP64—1_) 


--*NATURAL— 
'_PACKSTRUCT ( 1 


) | ENUM ( 


* SMALL 


*NODEP 


-MAKEDEP (—+fi | 
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> 
*NONE 
_PPGENOPT ( ) 
*DFT. 
—*GENLINE—— 
*RMVCOMMENT 
'_*NORMVCOMMENT—  ‘—*NOGENLINE— 
—*RMVCOMMENT—— 
—*GENLINE a] 
'_*NOGENLINE '_*NORMVCOMMENT— 
>. > 
(6) —*CURLIB/ | 
__PPSRCFILE( -file-name—) 
_library-name/— 
>. > 
(6) --*MODULE——— | (6) 
_PPSRCMBR( __membername ) PPSRCSTMF ( ) 
L-pathname— 
*SRCSTMF— 
> > 
*NONE 
INCDIR( Y__directory-name ) 
>. > 
*NONE | 
CSOPT ( ) 
_'__compiler-service-options-string—' 
>. > 
*NONE | 
LICOPT( ) 
'_'_licensed-Internal-Code-Options-String—'— 
>. > 
--*UNSIGNED— | 
__DFTCHAR (—+—*S IGNED——_—) 
>. > 
* SOURCE | 
'_TGTCCSID( *JOB ) 
*HEX 
coded-character-set-identifier— 
>. >< 
(2) (8) *NONE i 
_TEMPLATE( al TEMPLATE Details aa 
OPTION Details: 
(1) (2) (1) 
*NOAGR *NOBITSIGN *DIGRAPH *NOEVENTF— 
| 
> 
(1) (2) (1) Lx EVENTF— 
-*AGR————_—-__ -*BITSIGN ‘_*NODIGRAPH 
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(6) 


—*NOEXPMAC *NOFULL *GEN *NOINCDIRFIRST— 
>. a 
L_+EXPMAC *FULL (6) L_+INCDIRFIRST—— 
L_*NOGEN 
(2) (2) 
*LOGMSG *LONGLONG *NORTTI 
>. > 
»*NOLOGMSG (2) (2) 
L_*NOLONGLONG L-*RTTIALL 
(2) 
L_»RTTITYPE 
(2) 
L_+RTTICAST 
(1) (6) (1) 
—*NOPPONLY *NOSECLVL *NOSHOWINC— 
> a 
(1) (6) (1) L_*SHOWINC-—— 
L*PPONLY. L*SECLVL 
(1) 
—*NOSHOWSKP. *SHOWSRC *NOSHOWSYS *NOSHOWUSR— 
> > 
(1) L_xNOSHOWSRC— «SHOWSYs—+ ‘«SHOWUSR—— 
L_*SHOWSKP 
(1) 
—*STDINC *NOSTDLOGMSG *NOSTRUCREF *NOSYSINCPATH— 
>. > 
L«NOSTDINC L«*STDLOGMSG— (1) Lx«SYSINCPATH—— 
L_»STRUCREF 
*NOXREF- *NOXREFREF— 
> | 
*XREF. *XREFREF—— 
CHECKOUT Details: 
(2) (1) 
*NONE *NOCLASS *NOCOND *NOCONST 


*ALL (2) 
*USAGE *CLASS L_*CONST 
(1) (1) 
—*NOEFFECT *NOENUM *NOEXTERN *NOGENERAL— 
>. > 
L_»EFFECT— (1) (1) L_+GENERAL—— 
«ENUM *EXTERN 
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(1) (1) (2) 
*NOGOTO *NOINIT *NOLANG *NOPARM 
(1) (1) (2) L_+PARM—— 
*GOTO *INIT *LANG 
(1) (1) 
*NOPORT: *NOPPCHECK: *NOPPTRACE: *NOREACH— 
L_»PORT— (1) (1) L_+*REACH—— 
*PPCHECK L_*PPTRACE 
(2) 
*NOTEMP: *NOTRUNC— 
> 
(2) L_*TRUNC-——! 
L_»TEMP. 


--*NOUNUSED 
| 
'—* UNUSED 


INLINE Details: 


*OFF 
*ON 


| snonuto 
*AUTO 


INLINE Details (continued) i 


INLINE Details (continued): 


| | 
250 | 
1-65535 
'—*NOLIMIT 2000 | 
1-65535 
'—*NOLIMIT *NO | 
*YES 
TEMPLATE Details: 
--* TEMPINC 1 *NO 
| —-directory-pathname | 
1 65535 *WARN 
'—* ERROR 
Notes: 
1 Ccompiler only 


2 
3 
4 
5 
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C++ compiler only 
C compiler default setting 
C++ compiler default setting 


All parameters preceding this point can be specified positionally. 
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6 Create Module command only. 
7 Create Bound Program command only. 


8 Applicable only when using the Integrated File System (IFS). 


Control Language Command Options 


The following describes the keywords for the CRTCMOD, CRTCPPMOD, 
CRTBNDC, and CRTBNDCPP commands. In most cases the keywords are identical 
for any of the commands. Differences are noted where they exist. 


The term object is used throughout the descriptions, and will have one of two 

meanings: 

* If you are using the CRTCMOD or CRTCPPMOD commands, object means 
module object. 

* If you are using the CRTBNDC or CRTBNDCPP commands, object means 
program object. 


MODULE 


PGM 


Valid only on the CRTCMOD and CRTCPPMOD commands. Specifies the module 
name and library for the compiled ILE C or C++ module object. 


—*CURLIB/ 
[MODULE ( module-name—) | 
_library-name/— 


*CURLIB 
This is the default library value. The object is stored in the current library. If a 
job does not have a current library, QGPL is used. 


library-name 
Enter the name of the library where the object is to be stored. 


module-name 
Enter a name for the module object. 


Valid only on the CRTBNDC and CRTBNDCPP commands. Specifies the program 
name and library for the compiled ILE C or C++ program object. 


—*CURLIB/ 
|-—PGM ( program-name—) | 
_library-name/ 


*CURLIB 
This is the default library value. The object is stored in the current library. If a 
job does not have a current library, QGPL is used. 


library-name 
Enter the name of the library where the object is to be stored. 


program-name 
Enter a name for the program object. 
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SRCFILE 


Specifies the source physical file name and library of the file that contains the ILE 
C or C++ source code that you want to compile. 


(xxx) (xx) 


QCPPSRC 
(xxx) («*x) 
*LIBL/ QCSRC 
SRCFILE( ) 
*CURLIB/ source-file-name 


library-name/— 


*LIBL 
This is the default library value. The library list is searched to find the library 
where the source file is located. 


*CURLIB 
The current library is searched for the source file. If a job does not have a 
current library, QGPL is used. 


library-name 
Enter the name of the library that contains the source file. 


QCSRC 
The default name for the source physical file that contains the member with 
the ILE C source code that you want to compile. 


QCPPSRC 
The default name for the source physical file that contains the member with 
the ILE C++ source code that you want to compile. 


source-file-name 
Enter the name of the file that contains the member with the ILE C or C++ 
source code. 


SRCMBR 
Specifies the name of the member that contains the ILE C or C++ source code. 


(xxx) 


*PGM 


(***) 
*MODULE 
SRCMBR ( ) 
_member-name 


*MODULE 
Valid only with the CRTCMOD or CRTCPPMOD commands. The module name 
that is supplied on the MODULE parameter is used as the source member 
name. This is the default when a member name is not specified. 


*PGM 
Valid only with the CRTBNDC or CRTBNDCPP commands. The program name 
that is supplied on the PGM parameter is used as the source member name. 
This is the default when a member name is not specified. 
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member-name 
Enter the name of the member that contains the ILE C or C++ source code. 


SRCSTMF 


TEXT 


Specifies the path name of the stream file containing the ILE C or C++ source code 
that you want to compile. 


| | 
| 
'_SRCSTMF ( 


J 
aeehhane 


The path name can be either absolutely or relatively qualified. An absolute path 
name starts with ’/’; a relative path name starts with a character other than ’/’. If 
absolutely qualified, then the path name is complete. If relatively qualified, the 
path name is completed by pre-pending the job current working directory to the 
path name. 


Notes: 
1. The SRCMBR and SRCFILE parameters cannot be specified with the SRCSTMF 
parameter. 


2. If SRCSTMF is specified, then the following compiler options are ignored: 
* INCDIR( ) 
* OPTIONCINCDIRFIRST) 
* TEXT(?*SRCMBRIXT) 
* OPTION(STDINC) 
* OPTION(*SYSINCPATH) 
3. The SRCSTMF parameter is not supported in a mixed-byte environment. 


Allows you to enter text that describes the object and its function. 


| | 
| | 
fi -—*SRCMBRTXT- j 
TEXT ( satan) 
__'_description—' 


*SRCMBRITXT 
Default setting. The text description that is associated with the source file 
member is used for the compiled object. If the source file is an inline file or a 
device file, this field is blank. 


*BLANK 
Specifies that no text appears. 


description 
Enter descriptive text no longer than 50 characters, and enclose it in single 
quotation marks. The quotation marks are not part of the 50-character string. 
Quotation marks are supplied when the CRTCMOD or CRTCPPMOD prompt 
screens are used. 
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OUTPUT 


Specifies if the compiler listing is required or not. 


*NONE | 
OUTPUT ( * PRINT: ) 
__filename— *BLANK: *BLANK: | 
TITLE title SUBTITLE subtitle 


*NONE 
Does not generate the compiler listing. When a listing is not required, use this 
default to improve compile-time performance. When *NONE is specified, the 
following listing-related options are ignored if they are specified on the 
OPTION keyword: *AGR, *EXPMAC, *FULL, *SECLVL, *SHOWINC, 
*SHOWSKP, *SHWSRC, *SHOWSYS, *SHOWUSR, *SHWSRC, *STRUCREF, 
*XREF, and/or *XREFREF. 


*PRINT 
Generate the compiler listing as a spool file. 


The spool file name in WRKSPLF is the name of the object (program or 
module) name specified in the command and the User Data is the command 
name. 


This setting is ignored if specified together with TGTRLS(*PRV). 


filename 
The compiler listing is saved in the file name specified by this string. 


The listing name must be in Integrated File System (IFS) format, for example 
/home/mylib/listing/hello.lst. A data management file listing in library mylib 
should be specified as /OSYS.LIB/mylib.lib /listing.file/hello.mbr. If the string 
does not begin with a "/", it will be considered a subdirectory of the current 
directory or library. If the file does not exist, the file will be created. 


Data authority *WX is required to create an IFS listing. Data authority *WX, 
object authority *OBJEXIST and *OBJALTER are required to create a data 
management file listing via IPS. 


This setting is ignored if specified together with TGTRLS(*PRV). 


TITLE 
Specifies the title for the compiler listing. Possible TITLE values are: 
*BLANK 
No title is generated. 
title 
Specify a title string (maximum 98 characters) for the listing. 
SUBTITLE 
Specifies the subtitle for the compiler listing. Possible SUBTITLE values are: 
*BLANK 


No title is generated. 
subtitle 
Specify a subtitle string (maximum 98 characters) for the listing file. 


OPTION 


Specifies the options to use when the ILE C or C++ source code is compiled. You 
can specify them in any order, separated by a blank space. Unless noted otherwise 
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in the option descriptions, when an option is specified more than once, or when 
two options conflict, the last one that is specified is used. 


| 
—OPTION(— OPTION Details = 


OPTION Details: 


(***) (***) (***) 
*NOAGR *NOBITSIGN *DIGRAPH 
| > 
(***) (***) (***) 
_*AGR——————_-__ -*B I TSIGN-——————__ -* NODIGRAPH 
(***) 

—*NOEVENTF *NOEXPMAC *NOFULL *GEN 
>. > 

-*EVENTF—— ‘*EXPMAC * FULL (***) 

'—* NOGEN——— 
(***) 

—*NOINCDIRFIRST- *LOGMSG * LONGLONG 
>. > 

L-*INCDIRFIRST—~ '*NOLOGMSG— (***) 

'—* NOLONGLONG-————_ 
(***) (xxx) (xx) (***) 

—*NORTT I———————___ —*NOPPONLY oe ——— 

>. > 
(***) (xxx) (xx) (***) 
t-*RTT TALL *PPONLY *SECLVL 
(xxx) 
t-*RTTITYPE 
(xxx) 
L_*RTTICAST 


>-*NOSHOWUSR— 


—* SHOWUSR——' 
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*NOXREF-: ae 


—*X REF— *XREFREF—— 


The possible options are: 


*NOAGR 


Accepted but ignored by the C++ compiler. Default setting. Does not generate an 
aggregate structure map in the compiler listing. 


*AGR 
Accepted but ignored by the C++ compiler. Generates an aggregate structure map 
in the compiler listing. This map provides the layout of all structures in the 
source program, and shows whether variables are padded or not. 
OUTPUT(*PRINT) must be specified. 


The *AGR option overrides the *STRUCREF option. 


*NOBITSIGN 
Default setting. Bitfields are unsigned. 


*BITSIGN 


Bitfields are signed. 


*NODIGRAPH 
Default setting. Digraph character sequences are not recognized by the 
compiler. Syntax errors may result if diagraphs are encountered with this 
setting chosen. 


*DIGRAPH 


Digraph character sequences can be used to represent characters not found on 
some keyboards. Digraph character sequences appearing in character or string 
literals are not replaced during preprocessing. 


*NOEVENTF 
Default setting. Does not create an event file for use by CoOperative 
Development Environment/400 (CODE/400). 


*EVENTF 
Creates an event file for use by CoOperative Development Environment/400 
(CODE/400). The event file is created as a member in file EVFEVENT in the 
library where the created module or program object is to be stored. If the file 
EVFEVENT does not exist, it is automatically created. The event file member 
name is the same as the name of the object being created. An Event File is 
normally created when you create a module or program from within 
CODE/400. CODE/400 uses this file to provide error feedback integrated with 
the CODE/400 editor. 


*NOEXPMAC 
Default setting. Does not expand the macros in the source part of the listing or 
in the debug listing view. 


*EXPMAC 
Expands macros in the source part of the listing or in the debug listing view. 
One of OUTPUT(*PRINT) or DBGVIEW(*LIST or *ALL) must be specified. 


*NOFULL 
Default setting. Does not shows all compiler-ouput information in the listing or 
in the debug listing view. 
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*FULL 
Shows all compiler-ouput information in the listing or in the debug listing 
view. One of OUTPUT(*PRINT) or DBGVIEW(*LIST or *ALL) must be 
specified. 
This setting turns on all listing-related options. If *FULL is specified, you can 


turn off an individual listing option by specifying the *NO setting for that 
option after the *FULL option. 


*GEN 
Valid only with the CRTCMOD and CRTCPPMOD commands. Default setting. All 
phases of the compilation process are carried out. 


Specifying OPTION(*PPONLY) overrides the PPGENOPT(*NONE) 

and OPTION(*GEN) option settings. Instead, the following settings are 

implied: 

¢* PPGENOPT(*DFT) PPSRCFILE(QTEMP/QACZEXPAND) 
PPSRCMBR(*MODULE) for a data management source file, or, 


¢* PPGENOPT(*DFT) PPSRCSTMF(*SRCSTMBF) for an IFS source file. 
*NOGEN 


Valid only with the CRTCMOD and CRTCPPMOD commands. Compilation stops 
after syntax checking. No object is created. 


*NOINCDIRFIRST 
Default setting. The compiler searches for user include files in the root source 
directory first, and then in the directories specified by the INCDIR option. 


*INCDIRFIRST 
The compiler searches for user include files as follows: 


1. If you specify a directory in the INCDIR parameter, the compiler searches 
for file_name in that directory. 


2. If more than one directory is specified, the compiler searches the directories 
in the order that they appear on the command line. 


3. Searches the directory where your current root source file resides. 


4. If the INCLUDE environment variable is defined, the compiler searches the 
directories in the order they appear in the INCLUDE path 

5. If the *NOSTDINC compiler option is not chosen, search the default 
include directory /QIBM/include. 


*LOGMSG 
Default setting. Compilation messages are put into the job log. 


When you specify this option and the FLAG parameter, messages with the 
severity specified on the FLAG parameter (and higher) are placed in the job 
log. 


When you specify this option and a maximum number of messages on the 
MSGLMT parameter, compilation stops when the number of messages, at the 
specified severity, have been placed in the job log. 


*NOLOGMSG 
Does not put the compilation messages into the job log. 


*LONGLONG 
Default setting. The compiler recognizes and uses the longlong data type. 


*NOLONGLONG 
The compiler does not recognize the longlong data type. 
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*NORTTI 


Default setting. The compiler does not generate information needed for 
Run-Time Type Information (RTTI) typeid and dynamic_cast operators. 


*RTTIALL 


The compiler generates the information needed for the RTTI typeid and 
dynamic_cast operators. 


*RTTITYPE 


The compiler generates the information needed for the RTTI typeid operator, 
but the information for the dynamic_cast operator is not generated. 


*RTTICAST 
The compiler generates the information needed for the RTTI dynamic_cast 
operator, but the information for the typeid operator is not generated. 


*NOPPONLY 
Valid only with the CRTCMOD command. Default setting. The compiler runs the 
entire compile sequence when *GEN is left as the default for OPTION. 


Specifying PPGENOPT with any setting other than *NONE overrides the 
OPTION(*NOPPONLY) and OPTION(*GEN) option settings. 


Note: The PPGENOPT compiler option replaces OPTION(*NOPPONLY). 
Support for OPTION(*NOPPONLY) may be removed in future releases. 


*PPONLY 
Valid only with the CRTCMOD command. The preprocessor is run and the output 
is saved in the source file QACZEXPAND in library QTEMP. The 
member-name is the same as the name specified on the MODULE parameter. 
The rest of the compilation sequence is not run. When the job is submitted in 
batch mode, the output is deleted once the job is complete. 


If you specify SRCSTMEF, then the compiler saves the output in a stream file in 
your current directory. The file name is the same as the file on SRCSTMF with 


non 


a ".i" extension. 
Specifying OPTION(*PPONLY) overrides the PPGENOPT(*NONE) and 
OPTION(*GEN) option settings. Instead, the following settings are implied: 


* PPGENOPT(*DFT) PPSRCFILE(QTEMP/QACZEXPAND) 
PPSRCMBR(*MODULE) for a data management source file, or, 


* PPGENOPT(*DFT) PPSRCSTMF(*SRCSTMEP) for an IFS source file. 


Note: The PPGENOPT compiler option replaces OPTION(*PPONLY). Support 
for OPTION(*PPONLY) may be removed in future releases. 


*NOSECLVL 


Default setting. Does not generate the second-level message text in the listing. 


*SECLVL 
Generates the second-level message text in the listing. OUTPUT(*PRINT) must 
be specified. 


*NOSHOWINC 
Default setting. Does not expand the user include files or the system include 
files in the source listing or in the debug listing view. 


*SHOWINC 
Expands both the user-include files and the system-include files in the source 
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part of the listing or in the debug listing view. OUTPUT(*PRINT) or 
DBGVIEW(*ALL, *SOURCE, or *LIST) must be specified. 


This setting turns on the *SHOWUSR and *SHOWSYS settings, but those 
settings can be overridden by specifying *NOSHOWUSR and/or 
*NOSHOWSYS after *SHOWINC. 


*NOSHOWSKP 
Default setting. Does not include the statements that the preprocessor has 
ignored in the source part of the listing or in the debug listing view. The 
preprocessor ignores statements as a result of a preprocessor directive 
evaluating to false (zero). 


*SHOWSKP 
Includes all statements in the source listing or in the debug listing view, 
regardless of whether or not the preprocessor has skipped them. 
OUTPUT(*PRINT) or DBGVIEW(*ALL or *LIST) must be specified. 


*SHOWSRC 
Default setting. Shows the source statements in the source listing or in the 
debug listing view. OUTPUT(*PRINT) or DBGVIEW(*ALL, *SOURCE, or 
*LIST) must be specified. 


*NOSHOWSRC 
Does not show the source statements in the source listing or in the debug 
listing view. The *EXPMAC,*SHOWINC,*SHOWUSR,*SHOWSYS and 
*SHOWSKP listing options can override this setting if specifed after 
the* NOSHOWSRC option. 


*NOSHOWSYS 
Default setting. Does not expand the system include files on the #include 
directive in the source listing or in the debug listing view. 


*SHOWSYS 
Expands the system include files on the #include directive in the source listing 
or in the debug listing view. OUTPUT(*PRINT) or DBGVIEW(*ALL, *SOURCE, 
or *LIST) must be specified. System include files on the #include directive are 
enclosed in angle brackets (< >). 


*NOSHOWUSR 
Default setting. Does not expand the user include files on the #include 
directive in the source listing or in the debug listing view. 


*SHOWUSR 
Expands the user include files on the #include directive in the source listing or 
in the debug listing view. OUTPUT(*PRINT) or DBGVIEW(*ALL, *SOURCE, or 
*LIST) must be specified. User-include files on the #include directive are 
enclosed in double quotation marks (" "). Use this option to print the typedef 
that is generated when you use #pragma mapinc in your ILE C or C++ 
program to process externally described files. 


*STDINC 
Default setting. The compiler includes the default include path 
(/QIBM/include for IFS source stream files; QSYSINC for data management 
source file members) at the end of the search order. 


*NOSTDINC 
The compiler removes the default include path (/QIBM/include for IFS source 
stream files; QSYSINC for data management source file members) from the 
search order. 
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*NOSTDLOGMSG 
Default setting. The compiler does not produce stdout compiler messages. 


*STDLOGMSG 
The compiler will produce stdout compiler messages when working in the 
QShell environment. This option has no effect when compiling with 
TGTRLS(*PRV). 


*NOSTRUCTREF 
Default setting. Does not generate an aggregate structure map of all referenced 
struct or union variables in the compiler listing. 


*STRUCTREF 
Generates an aggregate structure map of all referenced struct or union 
variables in the compiler listing. This map provides the layout of all referenced 
structures in the source program, and shows whether variables are padded or 
not. 


*NOSYSINCPATH 
Default setting. The search path for user includes is not affected. 


*SYSINCPATH 
Changes the search path of user includes to the system include search path. In 
function this option is equal to changing the double-quotes in the user 
#include directive (#include "file_name") to angle brackets (#include 
<file_name>). 


*NOXREF 
Does not generate the cross-reference table in the listing. This is the default. 


*XREF 
Generates the cross-reference table that contains a list of the identifiers in the 
source code together with the line number in which they appear. 
OUTPUT(*PRINT) must be specified. 


The *XREF option overrides the *XREFREF option. 


*NOXREFREF 
Default setting. Does not generate the cross-reference table in the listing. 


*XREFREF 
Generates the cross-reference table, including only referenced identifers and 
variables in the source code, together with the line number in which they 
appear. OUTPUT(*PRINT) must be specified. 


The *XREF option overrides the *XREFREF option. 


CHECKOUT 


Specifies options you may select to generate informational messages that indicate 
possible programming errors. When you specify an option more than once, or 
when two options conflict, the last one that is specified is used. 


Note: CHECKOUT may produce many messages. To prevent these messages from 
going to the job log specify OPTION(*NOLOGMSG) and the source listing 
option OUTPUT(*PRINT). 


—CHECKOUT (—j CHECKOUT Details = 
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CHECKOUT Details: 


(***) (*«**) 
—*NONE— —*NOCLASS —*NOCOND: *NOCONST- 
| — | — 
*ALL (***) | sean (***) | 
*USAGE *CLASS * CONST, 
(***) (***) 
—*NOEFFECT *NOENUM *NOEXTERN —*NOGENERAL— 
> 
L»EFFECT—— (xxx) (xx) —* GENERAL—— 
-* ENUM *EXTERN 
(***) (***) (***) 
*NOGOTO *NOINIT *NOLANG *NOPARM 
> 
(«*x) (xx) (***) L+PARM—— 
«GOTO «INIT. -* LANG 
(xx) (***) 
*NOPORT *NOPPCHECK: *NOPPTRACE *NOREACH— 
> 
x PORT—— («**) (***) \_* REACH—— 
x PPCHECK _* PPTRACE. 
(***) 
*NOTEMP. *NOTRUNC— 
>. > 
(***) L_* TRUNC-—— 
* TEMP. 
-—-*NOUNUSED— 
. | 
'_* UNUSED—— 


The possible options are: 


*NONE 


Default setting. Disables all of the options for CHECKOUT. 


*ALL 


Enables all of the options for CHECKOUT. 


*USAGE 


. Equivalent to specifying *TRUNC, *ENUM, *EXTERN, “INIT, 
*PARM, *PORT, and *GENERAL. All other CHECKOUT options are 


disabled. 


7 Equivalent to specifying *COND. All other CHECKOUT options 
are disabled. 


*NOCLASS 


Default setting. Does not display info about class use. 


*CLASS 


Display info about class use. 
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*NOCOND 
Default setting. Does not warn about possible redundancies or problems in 
conditional expressions. 


*COND 
Warn about possible redundancies or problems in conditional expressions. 


*NOCONST 


Default setting. Does not warn about operations involving constants. 


*CONST 


Warn about operations involving constants. 


*NOEFFECT 
Default setting. Does not warn about statements with no effect. 


*EFFECT 
Warn about statements with no effect. 


*NOENUM 


Default setting. Does not list the usage of enumerations. 


*ENUM 


Lists the usage of enumerations. 


*NOEXTERN 


Default setting. Does not list the unused variables that have external 
declarations. 


*EXTERN 
Lists the unused variables that have external declarations. 


*NOGENERAL 
Default setting. Does not list the general CHECKOUT messages. 


*GENERAL 
Lists the general CHECKOUT messages. 


*NOGOTO 


Default setting. Does not list the occurrence and usage of goto statements. 


*GOTO 


Lists the occurrence and usage of goto statements. 


*NOINIT 


Default setting. Does not list the automatic variables that are not explicitly 
initialized. 
“INIT 


Lists the automatic variables that are not explicitly initialized. 


*NOLANG 
Default setting. Does not display information about the effects of the language 
level. 


*LANG 


Display information about the effects of the language level. 


*NOPARM 
Default setting. Does not list the function parameters that are not used. 
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*PARM 
Lists the function parameters that are not used. 


*NOPORT 
Default setting. Does not list the non-portable usage of the C or C++ language. 
*PORT 
Lists the non-portable usage of the C or C++ language. 
*NOPPCHECK 
Default setting. Does not list the preprocessor directives. 
*PPCHECK 
Lists all preprocessor directives. 
*NOPPTRACE 
Default setting. Does not list the tracing of include files by the preprocessor. 
*PPTRACE 
Lists the tracing of include files by the preprocessor. 
*NOREACH 
Default setting. Does not warn about unreachable statements. 
*REACH 
Warn about unreachable statements. 
*NOTEMP 
Default setting. Does not display information about temporary variables. 
*TEMP 
Display information about temporary variables. 
*NOTRUNC 
Default setting. Does not warn about the possible truncation or loss of data. 
*TRUNC 
Warn about the possible truncation or loss of data. 
*NOUNUSED 
Default setting. Does not check for unused auto or static variables. 
*UNUSED 
Check for unused auto or static variables. 
OPTIMIZE 


Specifies the level of the object’s optimization. 


10 
OPTIMIZE( 20 ) 


10 Default setting. Generated code is not optimized. This level has the shortest 
compile time. 


20 Some optimization is performed on the code. 
30 Full optimization is performed on the generated code. 


40 All optimizations done at level 30 are performed on the generated code. In 
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addition, code is eliminated from procedure prologue and epilogue routines 
that enable instruction trace and call trace system functions. Eliminating this 
code enables the creation of leaf procedures. A leaf procedure contains no calls 
to other procedures. Procedure call performance to a leaf procedure is 
significantly faster than to a normal procedure. 


INLINE 


Allows the compiler to consider replacing a function call with the called function’s 
instructions. Inlining a function eliminates the overhead of a call and can result in 
better optimization. Small functions that are called many times are good candidates 
for inlining. 


Note: When specifying an INLINE option, all preceding INLINE options must also 
be specified, including their defaults. 


INLINE ( F 


_ 


*NOAUTO 


*AUTO | INLINE Details 


INLINE Details (continued): 


| | 
250 | 

1-65535 

'—*NOLIMIT 2000 | 


1-65535 
*YES 


The possible INLINE options are: 


Inliner 
Specifies whether or not inlining is to be used. 


*OFF 
Default setting. Specifies that inlining will not be performed on the 
compilation unit. 

*ON 
Specifies that inlining will be performed on the compilation unit. If a 
debug listing view is specified, the inliner is turned off. 


Mode 
Specifies whether or not the inliner should attempt to automatically inline 
functions depending on their Threshold and Limit. 


*NOAUTO 
Specifies that only the functions that have been specified with the #pragma 
inline directive should be considered candidates for inlining. This is a 
default. 
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*AUTO 
Specifies that the inliner should determine if a function can be inlined 
based on the specified Threshold and Limit. The #pragma noinline 
directive overrides *AUTO. 


Threshold 
Specifies the maximum size of a function that can be a candidate for automatic 
inlining. The size is measured in Abstract Code Units. Abstract Code Units are 
proportional in size to the executable code in the function; C and C++ code is 
translated into Abstract Code Units by the compiler. 


250 
- Specifies a threshold of 250. This is the default. 
1-65535 
Specifies a threshold from 1 to 65535. 
*NOLIMIT 
Defines the threshold as the maximum size of the program. 
Limit 
Specifies the maximum relative size a function can grow before auto-inlining 
stops. 
2000 
Specifies a limit of 2000. This is the default. 
1-65535 
Specifies a limit from 1 to 65535. 
*NOLIMIT 
Limit is defined as the maximum size of the program. System limits may 
be encountered. 
Report 
Specifies whether or not to produce an inliner report with the compiler listing. 
*NO 
The inliner report is not produced. This is the default. 
*YES 


The inliner report is produced. OUTPUT(*PRINT) must be specified to 
produce the inliner report. 


MODCRTOPT 


Valid only with the CRTCMOD and CRTCPPMOD commands. Specifies the options to 
use when the *MODULE object is created. You can specify these options in any 
order, separated by spaces. When an option is specified more than once, or when 
two options conflict, the last one specified is used. 


| | 
| | 
L (x**)  —*NOKEEPILDTA | 
wooceropr(——} —___|_ 
L_«KEEPILDTA 


*NOKEEPILDTA 
Default setting. Intermediate language data is not stored with the *MODULE 
object. 


*KEEPILDTA 
Intermediate language data is stored with the *MODULE object. 
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DBGVIEW 


Specifies which level of debugging is available for the compiled object, and which 
source views are available for source-level debugging. Requesting a debug listing 
view will turn the inliner off. 


| | 
| | 
*NONE—— 


L_DBGVIEW(—+—*ALL ) 
«STMT— 
«SOURCE 
*LIST— 


The possible options are: 


*NONE 
Default setting. Disables all of the debug options for debugging the compiled 
object. 


*ALL 
Enables all of the debug options for debugging the compiled object and 
produces a source view, as well as a listing view. 


*STMT 
Allows the compiled object to be debugged using program statement numbers 
and symbolic identifiers. 


Note: To debug an object using the *STMT option you need a spool file listing. 


*SOURCE 
Generates the source view for debugging the compiled object. The 
OPTION(*NOSHOWINC, *SHOWINC, *SHOWSYS, *SHOWUSR) determines 
the content of the source view that is created. 


Note: The root source should not be modified, renamed or moved after the 
module has been created. It must be in the same library/file/member, in 
order to use this view for debugging. 


*LIST 
Generates the listing view for debugging the compiled object. The listing 
options (“EXPMAC, *NOEXPMAC, *SHOWINC, *SHOWUSR, *SHOWSYS, 
*NOSHOWINC, *SHOWSKP, *NOSHOWSKP) specified on the OPTION 
keyword determine the content of the listing view created, as well as the spool 
file listing. 


DEFINE 


Specifies preprocessor macros that take effect before the file is processed by the 
compiler. The format DEFINE(macro) is equivalent to DEFINE(‘macro=1’). 


| | 
| | 
*NONE 


DEFINE ( Y__'__name—! | ) 
'—name—=—value—' 


*NONE 
Default setting. No macro is defined. 
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name or name=value 
A maximum of 32 macros may be defined, and the maximum length of a 
macro is 80 characters. Enclose each macro in single quotation marks. The 
quotation marks are not part of the 80 character string and are not required 
when the CRTCMOD or CRTCPPMOD prompt screens are used. Single 
quotation marks are required for case-sensitive macros. Separate macros with 
blank spaces. 


Note: Macros, that are defined in the command, override any macro definition of 
the same name in the source. A warning message is generated by the 
compiler. Function-like macros such as #define max(a,b) ((a)>;(b):(a)?(b)) 
cannot be defined on the command. 


LANGLVL 


Specifies which group of library function prototypes are included when the source 
is compiled. When no LANGLVL is specified, the language level defaults to 


*EXTENDED. 
| 
—* EXTENDED: | 
__LANGLVL( *ANSI ) 
(xxx) 
* LEGACY 
*EXTENDED 


Default setting. Defines the preprocessor variable _ EXTENDED__ and 
undefines other language-level variables. ANSI-standard C and C++, and the 
IBM language extensions and system-specific features are available. This 
parameter should be used when all the functions of ILE C or C++ are to be 
available. 


*ANSI 
Defines the preprocessor variables __ ANSI__ and __STDC__ and undefines 
other language-level variables. Only ANSI-standard C and C++ is available. 


*LEGACY 


Undefines other language-level variables. Allow constructs compatible with 
older levels of the C++ language. 


SYSIFCOPT 


Specifies which integrated file system options will be used for C or C++ stream 
I/O operations in the module that is created. 


(***) 
—*IFS6410 
(xxx) («*x) 
t-*NOIFSIO *NOASYNCSIGNAL- 
_SYSIFCOPT ( ) 
«IFSIO (x) 
Lx ASYNCSIGNAL- 


*IFS641O 
Default setting for the C++ compiler. The object that is created will use 64-bit 
Integrated File System APIs that support C and C++ stream I/O operations on 
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files greater than two gigabytes in size. Using this option is equivalent to 
specifying SYSIFCOPT(*IFSIO *IFS64IO). 


*NOIFSIO 
Default setting for the C compiler. The object that is created will use the iSeries 
Data Management file system for C and C++ stream I/O operations. 


*IFSIO 
The object that is created will use the Integrated File System APIs for C and 
C++ stream I/O operations on files up to two gigabytes in size. 


*NOASYNCSIGNAL 
Default setting. Does not enable runtime mapping of synchronous signalling 
functions to asynchronous signalling functions. 


*ASYNCSIGNAL 
Enable runtime mapping of synchronous signalling functions to asynchronous 
signalling functions. Specifying this option causes C runtime to map the 
synchronous signal() and raise() functions to the asynchronous sigaction() and 
killQ) functions respectively. 


LOCALETYPE 


Specifies the type of locale support to be used by the object that is created. 


| | 
| | 
*LOCALE 


(xx) 
__LOCALETYPE( *CLD ) 
*LOCALEUCS2— 


*LOCALE 
Default setting. Objects compiled with this option use the locale support 
provided with the ILE C/C++ compiler and run time, using locale objects of 
type “LOCALE. This option is only valid for programs that run on V3R7 and 
later releases of the OS/400® operating system. 


*CLD 
Objects compiled with this option use the locale support provided with earlier 
releases of the ILE C compiler and run time, using locale objects of type *CLD. 


*LOCALEUCS2 
Objects compiled with this option store wide-character literals in two-byte 
form in the UNICODE CCSID (13488). 


FLAG 


Specifies the level of messages that are to be displayed in the listing. Only the 
first-level text of the message is included unless OPTION(*SECLVL) is specified. 


FLAG( 10 ) 


0 Default setting. All messages starting at the informational level are displayed. 


10 All messages starting at the warning level are displayed. 
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20 All messages starting at the error level are displayed. 


30 All messages starting at the severe error level are displayed. 


MSGLMT 


Specifies the maximum number of messages at a given severity that can occur 
before compilation stops. 


*NOMAX 30 | 
_MSGLMT (—+—0 32767 0 : ) 


*NOMAX 
Default setting. Compilation continues regardless of the number of messages 
that have occurred at the specified message severity level. 


0 32767 
Specifies the maximum number of messages that can occur at, or above, the 
specified message severity level before compilation stops. The valid range is 0 
to 32 767. 


30 Default setting. Specifies that message-limit messages at severity 30 can occur 
before compilation stops. 


0 Specifies that message-limit messages at severity 0 to 30 can occur before 
compilation stops. 


10 Specifies that message-limit messages at severity 10 to 30 can occur before 
compilation stops. 


20 Specifies that message-limit messages at severity 20 to 30 can occur before 
compilation stops. 


REPLACE 


Specifies whether the existing version of the object is to be replaced by the current 
version. 


| | 
| | 
*YES 


L_REPLACE (——*NO ) 


*YES 
Default setting. The existing object is replaced by the new version. The old 
version is moved to the library, QRPLOBJ, and renamed based on the system 
date and time. The text description of the replaced object is changed to the 
name of the original object. The old object is deleted at the next IPL if it has 
not been deleted. 


*NO 
The existing object is not replaced. When an object with the same name exists 
in the specified library, a message is displayed and compilation stops. 


USRPRF 


Valid only with the CRTBNDC and CRTBNDCPP commands. Specifies the user profile 
that is used when the compiled ILE C or C++ program object is run, including the 
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AUT 


authority that the program object has for each object. The profile of either the 
program owner or the program user is used to control which objects are used by 
the program object. 


| | 
| | 
(***) *USER 


USRPRF ( *OWNER ) 
*USER 
Default setting. The profile of the user that is running the program object is 
used. 
*OWNER 


The collective sets of object authority in the user profiles of both the program 
owner and the program user are used to find and access objects during the 
program object’s processing time. Objects that are created by the program are 
owned by the program’s user. 


Specifies the object authority to users who do not have specific authority to the 
object. The user may not be on the authorization list, or whose group has no 
specific authority to the object. 


| | 

| —*LIBCRTAUT—————————_ | 

AUT ( * CHANGE ) 

t—*USE 
*ALL 

t-* EXCLUDE 

__quthorization-list-name— 


*LIBCRTAUT 
Default setting. Public authority for the object is taken from the CRTAUT 
keyword of the target library (the library that contains the created object). This 
value is determined when the object is created. If the CRTAUT value for the 
library changes after the object is created, the new value does not affect any 
existing objects. 


*CHANGE 
Provides all data authority and the authority to perform all operations on the 
object except those that are limited to the owner or controlled by object 
authority and object management authority. The object can be changed, and 
basic functions can be performed on it. 


*USE 
Provides object operational authority, read authority, and authority for basic 
operations on the object. Users without specific authority are prevented from 
changing the object. 

*ALL 
Provides authority for all operations on the object except those that are limited 
to the owner or controlled by authorization list management authority. Any 
user can control the object’s existence, specify its security, and perform basic 
functions on it, but cannot transfer its ownership. 


*EXCLUDE 
Users without special authority cannot access the object. 
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authorization-list-name 
Enter the name of an authorization list of users and authorities to which the 
module object is added. The object is secured by this authorization list, and the 
public authority for the object is set to *AUTL. The authorization list must exist 
on the system when the CRTCMOD command is issued. 


TGTRLS 

Specifies the release level of the operating system for the object that is being 

created. 

| | 
—-* CURRENT 

‘_TGTRLS ( *PRV ) 

—release-level— 

*CURRENT 


Default setting. The object is used on the release of the operating system that is 
running on your system. For example, when V2R3M5 is run on your system, 
*CURRENT indicates you want to use the object on a system with Version 2 
Release 3 Modification 5 installed. You can also use the object on a system with 
any subsequent release of the operating system that is installed. 


Note: If V2R3M5 is run on the system, and the object is used on a system with 
V2R3M0 installed, specify TGTRLS(V2R3M0), not TGTRLS(#*CURRENT). 


*PRV 
The object is used on the previous release of the operating system. For 
example, if V2R3M5 is being run on the user’s system, if you specify *PRV you 
want to use the object on a system with V2R2MO0 installed. You can also use 
the object on a system with any subsequent release of the operating system 
that is installed. 


release-level 
Specify the release in the format VxRxMx. The object can be used on a system 
with the specific release or with any subsequent release of the installed 
operating system. Values depend on the current version, release, and 
modification level, and they change with each new release. If you specify a 
release-level that is earlier than the earliest release level supported by this 
command, you will receive an error message indicating the earliest supported 
release. 


Compiling for an operating system release earlier than V5R1MO may cause some 
settings of the following compiler options to be ignored: 


“CHECKOUT” on page 82 
“OPTION” on page 76 
“OUTPUT” on page 76 
“PRFDTA” on page 95) 


The following options are ignored completely when compiling for an operating 
system release earlier than V5R1MO: 


“CSOPT” on page 104 
“DFTCHAR” on page 105 
“DTAMDL” on page 99 


° “ENUM” on page 100 
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° |“INCDIR” on page 104 
° |“LICOPT” on page 105 
° |“MAKEDEP” on page 101 


“PACKSTRUCT” on page 100 
“PPGENOPT” on page 101 
“STGMDL” on page 99 
“TGTCCSID” on page 105 


ENBPFRCOL 


Specifies whether performance data measurement code should be generated in the 
module or program. The collected data that can be used by the system 
performance tool to profile an application’s performance. Generating the addition 
of the performance measurement code in a compiled module or program will 
result in slightly larger objects and may affect performance. 


| *PEP | 
'_ENBPFRCOL ( ) 
*ENTRYEXIT. *ALLPRC 
*FULL | *NONLEAF- 


*PEP 

Default setting. Performance statistics are only gathered on the entry and exit 
of the program entry procedure. Choose this value when you want to gather 
overall performance information for an application. This support is equivalent 
to the support that was formerly provided with the TPST tool. 


*ENTRYEXIT *NONLEAF 
Performance statistics are gathered on the entry and exit of all the program’s 
procedures that are not leaf procedures. This includes the program PEP 
routine. 


This choice is useful if you want to capture information on routines that call 
other routines in your application. 


*ENTRYEXIT *ALLPRC 
Performance statistics are gathered on the entry and exit of all the program’s 
procedures (including those that are leaf procedures). This includes the 
program PEP routine. 


This choice is useful if you want to capture information on all routines. Use 
this option when you know that all the programs called by your application 
were compiled with either the *PEP, *ENTRYEXIT or *FULL option. Otherwise, 
if your application calls other programs that are not enabled for performance 
measurement, the performance tool will charge their use of resources against 
your application. This would make it difficult to determine where resources are 
actually being used. 


*FULL *NONLEAF 
Performance statistics are gathered on entry and exit of all procedures that are 
not leaf procedures. Statistics are gathered before and after each call to an 
external procedure. 


*FULL *ALLPRC 
Performance statistics are gathered on the entry and exit of all procedures that 
includes leaf procedures. Also, statistics are gathered before and after each call 
to an external procedure. 
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Use this option if your application will call other programs that were not 
compiled with either *PEP, *ENTRYEXIT or *FULL. This option allows the 
performance tools to distinguish between resources that are used by your 
application and those used by programs it calls (even if those programs are not 
enabled for performance measurement). This option is the most expensive, but 
allows for selectively analyzing various programs in an application. 


*NONE 
No performance data will be collected for this module or program. Use this 
parameter when no performance information is needed, and the smaller 
module or size is desired. 


PFROPT 


Specifies the various options available to boost performance. 


| | 
| | 
-—*SETFPCA *NOSTRDONLY— 


L_PFROPT ( ) 
L*NOSETFPCA, ‘*STRDONLY—! 


*SETFPCA 
Default setting. Causes the compiler to set the floating point computational 
attributes to achieve the ANSI semantics for floating point computations. 


*NOSETFPCA 
No computational attributes will be set. This option is used when the module 
that you are compiling does not have any floating point computations in it. 


*NOSTRDONLY 
Specifies that the compiler must place strings into writeable memory. This is 
the default. 


*STRDONLY 
Specifies that the compiler may place strings into read-only memory. 


PRFDTA 


Specifies whether program profiling should be turned on for the module or 
program. Profiling can lead to better performance of your programs or service 
programs by improving the use of cache lines and memory pages in ILE 
applications. 


| | 
| | 
*NOCOL 


L_PRFDTA(—*COL ) 


Note: You cannot profile a stand-alone *MODULE object. 


*NOCOL 
Default setting. The collection of profiling data is not enabled. The module will 
not collect profiling data when it is included in a program or service program 
object. 


*COL 
The collection of profiling data is enabled. The module will collect profiling 
data when it is included in a program or service program object. 
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Use this option to generate code that will collect data at object creation time. 
This data will consist of the number of times basic blocks within procedures 
are executed, as well as the number of times procedures are called. 


Note: *COL has an effect only when the optimization level of the module is 
*FULL (30) or greater, and the TGTRLS(#*CURRENT) parameter option is 
specified. 


TERASPACE 


Specifies whether code generated by the compiler can recognize and work with 
addresses that reference teraspace storage locations. 


| | 
I | 
*NO 


—*NOTSIFC— 
L_TERASPACE ( YES ) 
L_«TSIFC— 


*NO 
Default setting. Code generated by the compiler is not enabled to handle 
teraspace storage addresses. 


*YES 
Code generated by the compiler is enabled to handle teraspace storage 
addresses, including parameters passed from other teraspace-enabled programs 
and service programs.. 


*NOTSIFC 
The compiler will by default not use teraspace versions of storage 
functions, such as malloc( ) or shmat( ). This is the default. 


*TSIFC 
The compiler will by default use teraspace versions of storage functions, 
such as malloc( ) or shmat( ), without requiring changes to the program 
source code. The compiler defines the _TERASPACE__ macro, and maps 
certain storage function names to their teraspace-enabled equivalents. For 
example, selecting this compiler option causes the malloc( ) storage 
function to be mapped to _C_TS_malloc( ). 


The DTAMDL (see page P9} and STGMDL (see page compiler options can be 
used together with the TERASPACE compiler option. Valid combinations of these 
options are shown in the following tables, along with the effects of selecting those 
combinations. 


ILE C/C++ Compiler Reference 


STGMDL 


DTAMDL(*P128) 
(®SNGLVL) (*TERASPACE) (*INHERIT) 
Module/program is * Module/program is * Depending on the storage 
designed to use designed to use model of the calling program, 
single-level store teraspace working the module is designed to use 
working storage. storage. either: 
Generated code supports |* Generated code supports | - single-level store working 
execution using: execution using: storage 
— single-level store — teraspace working — teraspace working storage 
working storage storage Depending on the storage 
— single-level store — single-level store model of the calling program, 
dynamic storage dynamic storage generated code supports 
Working storage can — teraspace dynamic execution using: 
only be accessed using storage — single-level store working 
16—-byte space pointers. |. Working storage can be storage 
Default pointer size is 16 accessed using either: — teraspace working storage 
bytes. — process local pointers — single-level store dynamic 
— 16-byte space pointers storage 
* Default pointer size is 16 — teraspace dynamic storage 
bytes. Default pointer size is 16 bytes. 
TERASPACE(*NO) Default setting Invalid combination Invalid combination 
Tere XeS Generated code also ¢ Default is to use Default is to use single-level 
NOTSIFC) supports execution using single-level store version store version of dynamic 
teraspace of dynamic storage storage interfaces. 
Default is to use interfaces. 
single-level store version 
of dynamic storage 
interfaces. 
al roa Generated code also ¢ Default is to use Default is to use teraspace 


supports execution using 
teraspace 

Default is to use 
teraspace version of 
dynamic storage 
interfaces. 
__TERASPACE _ macro 
is defined. 


teraspace version of 
dynamic storage 
interfaces. 
__TERASPACE _ macro 
is defined. 


version of dynamic storage 
interfaces. 
__TERASPACE _ macro is 
defined. 
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DTAMDL(*LLP64) 
(®SNGLVL) (*TERASPACE) (INHERIT) 
Module/program is * Module/program is * Depending on the storage 
designed to use designed to use teraspace model of the calling program, 
single-level store working storage. the module is designed to use 
working storage. * Generated code supports either: 
Generated code execution using: — single-level store working 
supports execution — teraspace working storage 
using: storage — teraspace working storage 
~ single-level store - single-level store * Depending on the storage 
working storage dynamic storage model of the calling program, 
— single-level store — teraspace dynamic generated code supports 
dynamic storage storage execution using: 
— teraspace * Working storage can be — single-level store working 
Working storage can accessed using either: storage 
only be accessed using — process local pointers — teraspace working storage 
16-byte space pointers. — 16-byte space pointers — single-level store dynamic 
Default pointer size is 8 : of fee storage 
wees * Default pointer size is 8 , 
ates: bytes. — teraspace dynamic storage 
¢ Working storage can be 
accessed using either: 
— (conditionally) process local 
pointers 
— 16-byte space pointers 
° Default pointer size is 8 bytes. 
TERASPACE(*NO) Invalid combination Invalid combination Invalid combination 
PERS eet XES Default is to use ¢ Default is to use ° Default is to use single-level 
NOTSIFC) single-level storage single-level storage storage version of dynamic 
version of dynamic version of dynamic storage interfaces. 
storage interfaces. storage interfaces. * __LLP64_IFC_ macro is 
__LLP64_IFC__ macro e _ LLP64_IFC__ macro is defined. 
is defined. defined 
near Mc Default is to use Recommended settings for |. Default is to use teraspace 
TSIFC) teraspace version of most effective use of version of dynamic storage 
dynamic storage teraspace interfaces. 
interfaces. * Default is to use teraspace |. TERASPACE and 
__TERASPACE__ and version of dynamic __LLP64_IFC__ macros are 
__LLP64_IFC__ macros storage interfaces. defined. 
are defined. e __TERASPACE _ and 
__LLP64_IFC__ macros are 
defined. 
To make the most effective use of teraspace, you should specify the following 
combination of options: 
TERASPACE(*YES *TSIFC) STGMDL(*TERASPACE) DTAMDL(*LLP64) 
For more information about teraspace storage, see Using Teraspace in ILE C/C++ 
Programmer's Guide, and Teraspace and single-level store in ILE Concepts. 
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STGMDL 


Specifies the type of storage (static and automatic) that the module object will use. 


| | 
-—*SNGLVL—— | 
'_STGMDL (—+—*TERASPACE——) 
—* INHERIT T—— 


*SNGLVL 
Default setting. The module or program will use the traditional single level 
storage model. Static and automatic storage for the object are allocated from 
single-level store, and can only be accessed using 16-byte pointers. The module 
may optionally access teraspace dynamic storage if the TERASPACE(*YES) 
option is specified. 


*TERASPACE 
The module or program will use the teraspace storage model. This is a new 
storage model that provides up to a 1-terabyte local address space for a single 
job. Static and automatic storage for the object are allocated from teraspace and 
can be accessed using either 8-byte or 16-byte pointers. 


*INHERIT 
Valid only with the CRTCMOD and CRTCPPMOD commands. The module created 
can use either single level or teraspace storage. The type of storage used will 
depend on the type of storage required by the caller. 


Use of STGMDL(*TERASPACE) or STGMDL(*INHERIT) together with 
TERASPACE(*NO) will be flagged as an error by the compiler, and compilation 
will stop. 


The STGMDL(*TERASPACE) and STGMDL(*INHERIT) settings are ignored if used 
together with the TGTRLS compiler option and a target release earlier than 
V5R1M0 is specified. 


For more information about valid combinations for the STGMDL, TERASPACE, 


and DTAMDL compiler options, see|“TERASPACE” on page 96 


For more information about the types of storage available on iSeries systems, see 
Teraspace and single-level store in ILE Concepts. 


DTAMDL 


Specifies how pointer types will be interpreted in absence of an explicit modifier. 
The __ptr64 and __ptr128 type modifiers and the datamodel pragma override the 
setting of the DIAMDL compiler option. 


| | 
| | 
*P128 


__DTAMDL ( *LLP64 ) 


*P128 
Default setting. The size of int, long, and pointer data types are 4, 4, and 16 
bytes respectively. 


*LLP64 
The size of int, long, and pointer data types are 4, 4, and 8 bytes respectively, 
and the compiler will define the macro __LLP64_IFC_. 
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Use of DTAMDL(*LLP64) together with TERASPACE(*NO) will be flagged as an 
error by the compiler, and compilation will stop. 


DTAMDL(*LLP64) is ignored if the TGTRLS compiler option specifies a target 
release earlier than V5SR1MO. 


See pragma|“datamodel” on page 31|for more information. 


For more information about valid combinations for the STGMDL, TERASPACE, 


and DITAMDL compiler options, see|“TERASPACE” on page 96 
PACKSTRUCT 


Specifies the alignment rules to use for members of structures, unions and classes 
in the source code. PACKSTRUCT sets the packing value to be used for the 
members of structures, but not for the structures themselves. 


If the data types are by default packed along boundaries smaller than those 
specified by #pragma pack, they are still aligned along the smaller boundaries. For 
example: 


* Type char is always aligned along a 1-byte boundary. 

* 16-byte pointers will be aligned on a 16-byte boundary. PACKSTRUCT, _Packed, 
and #pragma pack cannot alter this. 

* 8-byte pointers can have any alignment, but 8-byte alignment is preferred. 


For more information on packing and alignment, see pragma |pack” on page 56 


| | 
| | 
*NATURAL 


L_PACKSTRUCT(—+-1 ) 
2 
4. 


*NATURAL 
Default setting. The natural alignment for the members of structures is used. 


Structures and unions are packed along 1-byte boundaries. 
Structures and unions are packed along 2-byte boundaries. 


Structures and unions are packed along 4-byte boundaries. 


ao F NS 


Structures and unions are packed along 8-byte boundaries. 


16 Structures and unions are packed along 16-byte boundaries. 


ENUM 


Specifies the number of bytes the compiler uses to represent enumerations. This 
becomes the default enumeration size for the object.. A #pragma enum directive 
overrides this compile option. 


100 ILE C/C++ Compiler Reference 


* SMALL 


ENUM(—+-1 ) 
2 
4 
Lx INT— 
*SMALL 


Default setting. Use the smallest possible size for an enum, as appropriate to 
the given enum value. 


1 Make all enum variables 1 byte in size, signed if possible 
2 Make all enum variables 2 bytes in size, signed if possible 
4 Make all enum variables 4 bytes in size, signed if possible 
*INT 
7 Use the ANSI C Standard enum size ( 4-bytes signed). 


: Use the ANSI C++ Standard enum size ( 4-bytes signed; unless the 
enumeration value > 2°'-1). 


MAKEDEP 


Creates an output file containing targets suitable for inclusion in a description file 
for the qshell make command. 


| | 
*NODEP. | 
_MAKEDEP (—1—fi le-name——) 


*NODEP 
Default setting. The option is disabled and no file is created. 


file-name 
Specifies an IFS path indicating the location and name of the resulting output 
file. 


The output file contains a line for the input file and an entry for each include 
file. It has the general form: 

file_name.o:file_name.c 

file name.o:include_file_name Include files are listed according to the search 
order rules for the #include preprocessor directive. If an include file is not 
found, it is not added to the output file. Files with no include statements 
produce output files containing one line that lists only the input file name. 


PPGENOPT 


Valid only with the CRTCMOD or CRTCPPMOD commands. Lets you specify outputs 
generated by the preprocessor. 


Chapter 4. Control Language Commands 101 


102 


*NONE 


L_PPGENOPT ( ) 
*DFT 
—*GENLINE—— 
*RMVCOMMENT-———+_1_ | 
L_+NORMVCOMMENT— ‘—*NOGENLINE— 
—*RMVCOMMENT—— 
*GENLINE 
| NOGENLINE L_*NORMVCOMMENT— 
*NONE 


Default setting. No outputs are generated by the preprocessor. Selecting this 
option disables the PPSRCFILE, PPSRCMBR, and PPSRCSTMF options. 


*DFT 
Equivalent to specifying PPGENOPT(*RMVCOMMENT *GENLINE). 


*RMVCOMMENT 
Preserves comments during preprocessing. 


*NORMVCOMMENT 
Does not preserve comments during preprocessing. 


*NOGENLINE 
Suppresses #line directives in the preprocessor output. 


*GENLINE 
Produces #line directives in the preprocessor output. 
Notes: 


1. Specifying the PPGENOPT compiler option with any setting other than 
*NONE forces the input of either: 


¢ PPSRCFILE and PPSRCMBR, or, 
¢ PPSRCSTME, which in turn forces the input of SRCSTMF. 


2. Specifying PPGENOPT with any setting other than *NONE 
overrides the OPTION(*NOPPONLY) and OPTION(*GEN) option settings. 


a: Specifying OPTION(*PPONLY) overrides the 
PPGENOPT(*NONE) and OPTION(*GEN) option settings. Instead, the 
following settings are implied: 

* PPGENOPT(*DFT) PPSRCFILE(QTEMP/QACZEXPAND) 
PPSRCMBR(**MODULE) for a data management source file, or, 
* PPGENOPT(*DFT) PPSRCSTMF(*SRCSTMEF) for an IFS source file. 

4. The PPGENOPT compiler option is ignored if the TGTRLS compiler option 
specifies a target release earlier than V5R1MO. 


PPSRCFILE 


Valid only with the CRTCMOD or CRTCPPMOD commands. This option is used 
together with the PPGENOPT option to define where the preprocessor output 
object is stored. 


I | 
[ (***) -—*CURLIB/ J 
PPSRCFILE (| —___-9 le-name—) 
_library-name/ 
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*CURLIB 
Default setting. The object is stored in the current library. If a job does not have 
a current library, QGPL is used. 


library-name 
The name of the library where the preprocessor output is stored. 

file-name 
The physical file name under which the preprocessor output is stored. The file 
is created if it does not already exist. 

Notes: 


1. The PPSRCMBR and PPSRCFILE options cannot be specified with the 
PPSRCSTMF option. 


2: Specifying OPTION(*PPONLY) for a data management file 
implies the following settings: 
* PPGENOPT(*DFT) PPSRCFILE(QTEMP/QACZEXPAND) 
PPSRCMBR(*MODULE) 


PPSRCMBR 


Valid only with the CRTCMOD or CRTCPPMOD commands. This option is used 
together with the PPGENOPT option to define the name of the member where 
preprocessor output is stored. 


I | 
(xxx)  —*MODULE | 
-_PPSRCMBR (——————nembe rname——) 


*MODULE 
The module name that is supplied on the MODULE parameter is used as the 
source member name. This is the default when a member name is not 
specified. 

member-name 
Enter the name of the member that will contain the preprocessor output. 


Notes: 


1. The PPSRCMBR and PPSRCFILE options cannot be specified with the 
PPSRCSTMF option. 


2. Specifying OPTION(*PPONLY) for a data management file 
implies the following settings: 
* PPGENOPT(*DFT) PPSRCFILE(QTEMP/QACZEXPAND) 
PPSRCMBR(*MODULE) 


PPSRCSTMF 


Valid only with the CRTCMOD or CRTCPPMOD commands. This option is used 
together with the PPGENOPT option to define the IFS stream path name where 
preprocessor output is stored. 


| | 
| 

(xx) 

|_PPSRCSTMF ( ) 

L-pathname— 


'—* SRCSTMF— 


Chapter 4. Control Language Commands 103 


path-name 
Enter the IFS path of the file that will contain the preprocessor output. The 
path name can be either absolutely or relatively qualified. An absolute path 
name starts with ’/’; a relative path name starts with a character other than ’/’. 
If absolutely qualified, then the path name is complete. If relatively qualified, 
the path name is completed by pre-pending the job current working directory 
to the path name. 


*SRCSTMF 
If this setting is chosen, you must also select the SRCSTMF command option. 
Preprocessor output is saved to the current directory under the same base 
filename specified by the SRCSTMF command option, but with a filename 
extension of .i. 


Notes: 


1. The PPSRCMBR and PPSRCFILE options cannot be specified with the 
PPSRCSTMF option. 


2. The SRCSTMF parameter is not supported in a mixed-byte environment. 


a: Specifying OPTION(*PPONLY) for an IFS file implies the 
following settings: 


¢* PPGENOPT(*DFT) PPSRCSTMF(*SRCSTMPF) 


INCDIR 


Lets you redefine the path used to locate include header files when compiling a 
source stream file. This option is ignored if the source file’s location is not defined 
as an IFS path with the SRCSTMF compiler option, or if the full absolute path 
name is specified on the #include directive. 


| | 
| 
*NONE 


INCDIR( Y _directory-name ) 


*NONE 
Default setting. No directories are inserted at the start of the default user 
include path. 


directory-name 
Specifies a directory name to be inserted at the start of the default user include 
path. More than one directory name can be entered. Directories are inserted at 
the start of the default user include path in the order they are entered. 


CSOPT 


This option lets you specify one or more compiler service options. Valid option 
strings will be described in PTF cover letters and release notes. 


| | 
I 
—*NONE | 
CSOPT ( ) 
__'__compiler-service-options-string—' 


*NONE 
Default setting. No compiler service options selected. 
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compiler-servicing-options-string 
Specified compiler service options are used when creating a module object. 


LICOPT 


Specifies one or more Licensed Internal Code compile-time options. This parameter 
allows individual compile-time options to be selected, and is intended for the 
advanced programmer who understands the potential benefits and drawbacks of 
each selected type of compiler option. 


| | 
| | 
*NONE 


“LICOPT( ) 
'_'_l icensed-Internal-Code-Options-String—'— 


The possible options are: 


*NONE 
Default setting. No compile-time optimization is selected. 


Licensed-Internal-Code-options-string 
The selected Licensed Internal Code compile-time options are used when 
creating the module/program object. Certain options may reduce your ability 
to debug the created module/program. See the ILE Concepts Book for more 
information about LICOPT options. 


DFTCHAR 
Instructs the compiler to treat all variables of type char as either signed or 
unsigned. 
| | 
--*UNSIGNED— 
'_DFTCHAR ( *STGNED ) 
*UNSIGNED 


Default setting. Treats all variables declared as type char as type unsigned 
char. The CHAR UNSIGNED macro is defined. 


*SIGNED 
Treats all variables declared as type char as type signed char, and defines the 
_CHAR_SIGNED macro. This setting is ignored if the TGTRLS option specifies 
a target release earlier than V5R1MO. 


TGTCCSID 


Specifies the target coded character set identifier (CCSID) of the resulting module. 
The module’s CCSID identifies the coded character set identifier in which the 
module’s character data is stored. This includes character data used to describe 
literals, comments and identifier names described by the source, with the exception 
of identifier names for CCSIDs 5026, 930 and 290. 


The TGTCCSID option will also determine the CCSID of character values used in 
listings. However, listings sent to a spool file will be in the job’s CCSID because 


that is the CCSID of the spool file. 


This option is ignored when targeting a compile for a release previous to V5R1. 
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* SOURCE 

'_TGTCCSID( * JOB ) 
*HEX: 

'-coded-character-set-identifier— 


*SOURCE 

Default setting. The CCSID of the root source file is used. 
*JOB 

The CCSID of the current job is used. 
*HEX 


The CCSID 65535 is used, indicating that character data is treated as bit data 
and is not converted. 


coded-character-set-identifier 
Specifies a specific CCSID to be used. 


TEMPLATE 


Applicable only when using the Integrated File System (IFS). Specifies options to 
customize C++ template generation. 


| | 
(*x*) (4x) *NONE | 
_TEMPLATE ( | TEMPLATE Details ‘ae 


TEMPLATE Details: 


*TEMPINC 1 *NO: 
directory-pathname-}——} 4} —___}#_________ 
1 65535: *WARN 
—* ERROR— 


The possible options are: 


*NONE 
No automatic template instantiation file is created. The compiler instantiates all 
templates whose full implementation is known if an object of that template 
class is defined, or if a call is made to that template function within the 
module. If the full implementation is not known (for example, you have a 
template class definition, but not the definition of the methods of that template 
class), that template is not instantiated within the module. 


Note: This can cause code duplication in program executables where template 
specifications are used in more than one module. 


*TEMPINC 
Automatic template instantiation is turned on, and the resulting template 
instantiation files are placed into the tempinc subdirectory, relative to the 
current directory. The tempinc subdirectory is created if it does not already 
exist. The template instantiation files created have the root name of the header 
file in which the template was found and a filename extension of .C. If 
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template instantiation files already exist, the compiler seaches them to see if a 
given template instantiation already exists before adding it to an instantiation 
file 

directory-pathname 
Same as *TEMPLATE(*TEMPINC), except that template instantiation files are 
placed is a specified directory location. The directory path can be relative to 
the current directory, or it can be an absolute directory path. 


If the specified directory does not exist, it is created. However, an error 
condition results if the specified directory path contains a directory that does 
not exist, for example, TEMPLATE(/source/subdirl/tempinc) when subdir 
does not exist. 

1 65535 
Specifies the maximum number of template include files to be generated by the 


*TEMPLATE(*TEMPINC) option for each header file. If not specified, this 
setting defaults to 1. The maximum value for this setting is 65535. 


*NO 
Default setting if TEMPLATE(*NONE) is not in effect.. Do not parse the 
template implementations. This reduces the number of errors issued in code 
written for previous versions of VisualAge C++ and predecessor products. 


Note: Regardless of the setting of this and the next two options, error 
messages are produced for problems that appear outside 
implementations. For example, errors found during the parsing or 
semantic checking of constructs such as the following, always cause 
error messages: 

* return type of a function template 

* parameter list of a function template 

* member list of a class template 

* base specifier of a class template 
*WARN 

Parses template implementations and issues warning messages for semantic 

errors. 


*ERROR 
Treats problems in template implementations as errors, even if the template is 
not instantiated. 
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Chapter 5. Using the ixlc Command to Invoke the C/C++ 
Compiler 


The ixle command lets you invoke the compiler and specify compiler options from 
a Windows client or iSeries Qshell command line. Module binder commands can 
be specified. The ixlc command can be used together with AIX or Windows make 
files to control compilation. 


Using ixic on a Windows Client 


When using the Windows client version of ixlc, you can: 


* Compile source files residing on your Windows client without first having to 
transfer them to an iSeries system. 


* Compile data management source code residing on an iSeries system. 

* Compile IFS source code residing on an iSeries system. 

* Use header files residing on either the Windows client, the iSeries system, or 
both. 


You must install the CODE component of IBM WebSphere Development Tools for 
iSeries if you want to use ixlc from the command line of a Windows client. 


Using ixic in Qshell 


When using the iSeries version of ixle on the "green screen” Qshell command line, 
you can: 


* Compile data management source code residing on an iSeries system. 
* Compile IFS source code residing on an iSeries system. 
* Use header files residing on the iSeries system. 


ixlc Command and Options Syntax 


Basic syntax for the ixlc command is: 


v 


pe—ixlc 


-? | -C | -+ | a Sanne! | onptien opis 


“‘Letipeeee! = 
-B—"—binder_cmd—" 


where: 


ixlc Basic compiler command invocation. By default, the ixlc command 
instructs the compiler to create a bound program. 


=e Specifying this flag displays help for the ixlc command. 
“Cc Specifying this flag instructs the compiler to create a module. 


-+ Specifying this flag invokes the C++ compiler. 
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pgm_source 


Specifies the name of the program source file being compiled. You can 
compile an IFS source program or data management source program by 
providing the source name as: 


qsys.lib/.../name.mbr 


Alternately, you can also compile a data management source program by 
using the -qsrcfile(library/file) and -qsrcmbr (member) QShell compiler 
options to identify the location of the program source. 


compiler_opts 


Specifies the ixlc name of an ILE C/C++ compiler option. 


-B" binder_cmd" 


Specifies a binder command and options. For example: 
-B"CRTPGM PGM(library/target) MODULE(...)" 


Notes on Usage 


1. 
2: 


ixlc commands and options are case sensitive. 


It is possible to specify conflicting options when invoking the compiler. If this 
occurs, options specified later on the command line will override options 
specified earlier. For example, invoking the compiler by specifying : 

ixlc hello.c -qgen -qnogen 


is equivalent to specifying: 
ixlc hello.c -qnogen 


Some option settings are cumulative, and can be specified more than once on 
the command line without cancelling out earlier specifications of that same 
option. These options include: 


* settings within the OPTION compiler option group 

* settings within the CHECKOUT compiler option group 
* DEFINE compiler option 

* PPGENOPT compiler option 


ixlc Command Options 


The table below shows the mappings of Create Module and Create Bound Program 
compiler options to their ixle equivalents. Compiler options may have language 
and usage restrictions that are not shown in this table. For information on such 
restrictions, refer to the reference information for that option. 


Create Module/Create 4 F . : 
Bound Program Options Option Settings ixlc Equivalents and Notes 
“MODULE” on page 73 *CURLIB | libname/name -o[libname/name] 


“PGM” on page 73 


“SRCFILE” on page 74 


If library is not specified, the target object goes to the current library as specified by 
the current user profile. If the user does not have a current library, QGPL is assumed. 


*LIBL/ | *CURLIB/ | libname/ -qsrcfile=[*CURLIB/|filename 
*QCSRC | *QCPPSRC | filename -qsrcfile=[*LIBL/]filename 
-qsrcfile=[libname /|filename 


“SRCMBR’” on page 74 *MODULE | modname -qsrcmbr=mbrname 
“SRCSTME” on page 75 pathname (none, uses default pathname) 
“TEXT” on page 75 *SRCMBRTEXT | *BLANK | text -qtext="text" 
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Create Module/Create 
Bound Program Options 


Option Settings 


ixlc Equivalents and Notes 


“OUTPUT” on page 76 *PRINT | *NONE | filename -qprint 
*BLANK | string -qnoprint 
*BLANK | string -qoutput="filename" 
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Create Module/Create 
Bound Program Options 


Option Settings 


ixlec Equivalents and Notes 


“OPTION” on page 76 


*AGR | *NOAGR 


-qagr 


*BITSIGN | *NOBITSIGN 


-qbitfields=signed 
-qbitfields=unsigned 


*DIGRAPH | *NODIGRAPH -qdigraph 
-qnodigraph 
*EVENTF | *NOEVENTF -qeventf 
-qnoeventf 
*EXPMAC | *NOEXPMAC -qexpmac 
-qnoexpmac 
*FULL | *NOFULL -qfull 
-qnoful] 
*GEN | *NOGEN -qgen 
-qnogen 
*INCDIRFIRST | *NOINCDIRFIRST -qidirfirst 
*LOGMSG | *NOLOGMSG -qlogmsg 
-qnologmsg 
*LONGLONG | *NOLONGLONG -qlonglong 
-qnolonglong 
*NORTTI | *RTTIALL | *RTTITYPE | *RTTICAST | -qnortti 
-qrtti=al] 


-qrtti=typeinfo 
-qrtti=dynamiccast 


*PPONLY | *NOPPONLY -qpponly 

*SECLVL | *NOSECLVL -qseclvl 
-qnoseclvl 

*SHOWINC | *NOSHOWINC -qshowinc 


-qnoshowinc 


*SHOWSKP | *NOSHOWSKP -qshowskp 
-qnoshowskp 
*SHOWSRC | *NOSHOWSRC -qsource 
-qnosource 
*SHOWSYS | *NOSHOWSYS -qshowsys 
-qnoshowsys 
*SHOWUSR | *NOSHOWUSR -qshowusr 
*STDINC | *NOSTDINC -qstdinc 
-qnostdinc 
*STDLOGMSG | *NOSTDLOGMSG -qstdlogmsg 
-qnostdlogmsg 
*STRUCREF | *NOSTRUCREF -qrefagr 
*SYSINCPATH | *NOSYSINCPATH -qsysincpath 
-qnosysincpath 


* -qsysincpath searches for header files on the iSeries system. 


* -qnosysincpath searches for user-defined headers on the Windows client first, and 


then on the iSeries system. 


*XREF | *NOXREF 


-qxref=full 
-qattr=full 


*XREFREF | *NOXREFREF 


-qxref -qattr 
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Create Module/Create 
Bound Program Options 


Option Settings 


ixlc Equivalents and Notes 


NONE | *USAGE | *ALL -qinfo=cnd 
-qinfo=al] 
*CLASS | *NOCLASS -qinfo=cls 
*COND | *NOCOND -qinfo=cnd 
*CONST | *NOCONST -qinfo=cns 
*EFFECT | *NOEFFECT -qinfo=eff 
*ENUM | *NOENUM -qinfo=enu 
*EXTERN | *NOEXTERN -qinfo=ext 
*GENERAL | *NOGENERAL -qinfo=gen 
*GOTO | *NOGOTO -qinfo=got 
*INIT | *NOINIT -qinfo=ini 
*LANG | *NOLANG -qinfo=lan 
*PARM | *NOPARM -qinfo=par 
*PORT | *NOPORT -qinfo=por 
*PPCHECK | *NOPPCHECK -qinfo=ppc 
*PPTRACE | *NOPPTRACE -qinfo=ppt 
*REACH | *NOREACH -qinfo=rea 
*TEMP | *NOTEMP -qinfo=gnr 
*TRUNC | *NOTRUNC -qinfo=trd 
*UNUSED | *NOUNUSED -qinfo=use 
10 | 20 | 30 | 40 -qoptimize=10 
-qoptimize=20 
-qoptimize=30 
-qgoptimize=40 
-0 
-0 is equivalent to specifying 
-qgoptimize=40 
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Create Module/Create 
Bound Program Options 


Option Settings 


ixlec Equivalents and Notes 


“INLINE” on page 86 


“MODCRTOPT” on page 87; 


*OFF | *ON 
~~ *NOAUTO | *AUTO 
250 | 1-65535 | *NOLIMIT 
2000 | 1-65535 | *NOLIMIT 
*NO | *YES 


*KEEPILDATA | *NOKEEPILDATA 


-qnoinline 
"-qinline=optl opt2 opt3 opt4" 
where: 
* optl is one of: 
— noauto 
— auto 
* opt2 is one of: 
— 250 
— 1-65536 
— *NOLIMIT 
* opt3 is one of: 
- 2000 
— 1-65536 
— *NOLIMIT 
¢ opt4 is one of: 
— norpt 
— rpt 


One selection from each option 
group must be specified. Selections 
must be separated with a space, and 
double-quotes must be used to 
wrapper the entire option. For 
example: 


"-qinline=auto 400 3000 rpt" 


-qildta 
-qnoildta 


“DBGVIEW” on page 88 


*NONE | *ALL | *STMT | *SOURCE | *LIST 


-qdbgview=none 
-qdbgview=stmt 
-qdbgview=source 
-qdbgview=list 
-qdbgview=al 1 

“9 


-g is equivalent to specifying 
-qdbgview=*al1 


“DEFINE” on page 88 


*NONE | name | name=vailue 


-Dname 


Defines name with a value of 1. 


“LANGLVL” on page 89 


*EXTENDED | *ANSI | *LEGACY 


-qlanglvl=extended 
-qlanglvl=ans 
-qlanglvl=legacy 


“SYSIFCOPT” on page 89 


*NOIFSIO | **IFSIO | *IFS6410 


-qifsio=64 
-qnoifsio=64 


*ASYNCSIGNAL | *NOASYNCSIGNAL 


-qasyncsignal 
-qnoasyncsignal 


“LOCALETYPE” on page 90} 


*LOCALE | *LOCALEUCS2 | *CLD 


-qlocale=cld 
-qlocale=locale 
-qlocale=localeucs2 
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Create Module/Create 
Bound Program Options 


Option Settings 


ixlc Equivalents and Notes 


“FLAG” on page 90) 


® | 10 | 20 | 30 


-qflag=0 

-qflag=10 
-qflag=20 
-qflag=30 


“MSGLMT” on p 


© 
Q 
oO 
Ke) 
a 


*NOMAX | 0-32767 
30 | 0 | 10 | 20 


-qmsglmt=nomax 
-qmsglmt=0-32767 
-qmsglmt=30 
-qmsglmt=0 
-qmsglmt=10 
-qmsglmt=20 


“REPLACE” on page 9 


*YES | *NO 


-qreplace 
-qnoreplace 


= : 
ay 


“USRPRE” on page 9 


*USER | *OWNER 


-quser 
-qowner 


“AUT” on page 92 


*LIBCRTAUT | *CHANGE | *USE | *ALL 


*EXCLUDE 


-qaut=libcrtaut 
-qaut=all 
-qaut=change 
-qaut=use 
-qaut=exclude 


“TGTRLS” on page 9 


*CURRENT | *PRV | release_lvl 


-qtgtrls=current 
-qtgtrls=prv 
-qtgtr1s=VxRxMx 


“ENBPFRCOL” on page 94 


*PEP | *ENTRYEXIT | *FULL 
*NONLEAF | *ALLPRC 


-qenbpfrcol=pep 
-qenbpfrcol=entryexitnonleaf 
-genbpfrcol=entryexitallpre 
-qgenbpfrcol=ful Inoleaf 
-qgenbpfrcol=fullallpre 


“PFROPT” on page 9 


*SETFPCA | *NOSETFPCA -qsetfpca 
-qnosetfpca 
*NOSTRDONLY | *STRDONLY -qnoro 
-qro 


“PRFDTA” on page 9 


*NOCOL | *COL 


-qnoprofile 
-qprofile 


-qprfdta=nocol 
-qprfdta=col 


“TERASPACE” on page 9 


*NO | *YES 
*NOTSIFC | *TSIFC 


-qteraspace=no 
-qteraspace=yes 
-qteraspace=notsifc 
-qteraspace=tsifc 


D 


“STGMDL” on page 9 


*SNGLVL | *TERASPACE | *INHERIT 


-qstoragemodel=snglv1 
-qstoragemodel=teraspace 
-qstoragemodel=inherit 


“DTAMDL” on page 99 


**P128 | *LLP64 


-qdatamodel=P128 
-qdatamodel=LLP64 


“PACKSTRUCT” on 
page 10 


: 


1|2|4 | 8 | 16 | *NATURAL 


-qalign=1 
-qalign=2 
-qalign=4 
-galign=8 
-qalign=16 
-qalign=natural 
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Create Module/Create 
Bound Program Options 


Option Settings 


ixle Equivalents and Notes 


“ENUM” on page 100 1 | 2 | 4 | *INT | *SMALL -qenum=1 
-qenum=2 
-qenum=4 
-qenum=int 
-qenum=smal 1 
“MAKEDEP” on page 10 *NODEP | filename -Mnakefile 
“PPGENOPT” on page 10 *NONE | *DFT -P 
*RMVCOMMENT | *NORMVCOMMENT -qppcomment 
-qnoppcomment 
*GENLINE | *NOGENLINE -qppline 
-qnoppline 


“PPSRCFILE” on page 10 


[*CURLIB | libname]/filename 


-qppsrcfile=*curlib/filename 
-qppsrcfile=libname/ filename 
-qppsrcfile=filename 


“PPSRCMBR’” on page 10 


“PPSRCSTMF” on page 103 


*MODULE | mbrname 


pathname | *SRCSTMF 


-qppsrcmbr=*module 
-qppsrcmbr=mbrname 
-qppfile=filename 
-qppfile=*srcstmf 


“INCDIR” on page 104 


*NONE | pathname 


-Ipathname 


* When used on a Windows client command line, specifies directories on the client 


workstation. 


* When used on the Qshell command line, specifies directories on an iSeries system. 


Include environment variables are overwritten. 


“CSOPT” on page 104 
“LICOPT” on page 105 


string 


*NONE | string 


-qcsopt=string 


-qlicopt=string 


“DFTCHAR’” on page 105 


*SIGNED | *UNSIGNED 


-qchar=signed 
-qchar=unsigned 


“TGTCCSID” on page 105 


*SOURCE | *JOB | *HEX | ccsid# 


-qtgtccsid=source 
-qtgtccsid=job 
-qtgtccsid=hex 
-qtgtccsid=ccsid# 


“TEMPLATE” on page 106 


*NONE | pathname 


-qnotempinc 
-qtempinc=pathname 


1 - 65535 


-qtempmax=1-65535 


*NO | *WARN | *ERROR 


-qtmplparse=no 
-qtmp]parse=warn 
-qtmp1parse=error 
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Chapter 6. Using ixIclink to Create Programs 


The ixlclink command lets you invoke the OS/400 Create Program (CRTPGM) and 
Create Service Program (CRTSRVPGM) commands from a personal computer 
workstation. Command parameters are passed by ixlclink to the OS/400 CRTPGM 
or CRTSRVPGM programs, which in turn bind modules residing on an iSeries 
system into an ILE program or service program. 


You must install the CODE component of IBM WebSphere Development Tools for 
iSeries if you want to use the ixlclink command from the command line of a 
Windows client. 


Examples of ixlclink Usage 


1. The following ixlclink command invokes the OS/400 CRTPGM command to 
create a program. 


c:\>ixlclink -qpgm=usr/simple -qgen -qnodupproc -qmodule=usr/simplec 
-qtext="simple c program" 


It is equivalent to issuing the following CL command: 


CRTPGM PGM(usr/simple) module(usr/simplec) text('simple c program' ) 
option( *gen *nodupproc) 


2. The following ixlclink command invokes the OS/400 CRTSRVPGM command 
to create a service program. 


c:\>ixlclink -qsrvpgm=usr/simple "-qbnddir=temp/a temp/c" -qgen -qnodupproc 
-qmodule=usr/simplec -qtext="simple service program" 


is equivalent to issuing the following CL command: 


CRTSRVPGM SRVPGM(usr/simple) bnddir(temp/a temp/b) module(usr/simplec) 
text('simple service program' ) option( *gen *nodupproc) 

3. If the command line parameter includes one or more spaces, you need to use "” 
" to enclose the parameter. For example: 
-qbnddir="temp/a temp/b" 


is seen by CL as: 
bnddir(temp/a temp/b) 


If there is space in a string associated with a command line parameter, you 
need to use ’ ’ to quote the string and " " to quote the command line. For 
example: 


"-qtext='simple c'" 


is seen by CL as: 
text('simple c') 


For more information on creating programs or service programs, see Creating a 
Program and Creating a Service Program in ILE C/C++ Programmer's Guide. 
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ixiclink Command Options 
Most CRTPGM and CRTSRVPGM command options have ixlclink counterparts, as 


listed in the table below: 


CRTPGM and 

CRTSRVPGM Option Settings ixlclink Equivalents 

Command Options 

(none) (none) -? 

Displays help for the ixlclink command. 
PGM *CURLIB | library_name/name -qpgm=*CURLIB/name 
-qpgm=library_name/name 
-qpgm=name 

SRVPGM *CURLIB | library_name/name -qsrvpgm=*CURLIB/name 
-qsrvpgm=library_name/name 
-qsrvpgm=name 

MODULE *PGM -qmodule= *PGM | [ *LIBL/ | *CURLIB/ 
*LIBL/ | *CURLIB/ | *USRLIBL/ | lib_name/ | *USRLIBL/ | lib_name/] *ALL 
*ALL | generic_module_name | module_name generic_module_name | module_name 

TEXT *ENTMODTEXT | *BLANK | text -qtext="text" 

ENTMOD *FIRST | *ONLY | *PGM -qentmod=*FIRST | *ONLY | *PGM | [ 
*LIBL/ | *CURLIB/ | *USRLIBL/ | lib_name/ *LIBL/ | *CURLIB/ | *USRLIBL/ | 
module_name lib_name/] module_name 

BNDSRVPGM *NONE -qbndsrvpgm=*NONE | 
*LIBL/ | lib_name/ [ *LIBL/ | lib_name/] 

*ALL | srvr_pgm_name | generic_name *ALL | srv_pgm_name| generic_name 

BNDDIR *NONE -qbnddir= *NONE 
*LIBL/ | *CURLIB/ | *USRLIBL/ | lib_name/ dir |[ *LIBL/ | *CURLIB/ | 

*USRLIBL/ | lib_name/]dir 

ACTGRP *NEW | *CALLER | actgrpname -qactgrp=*NEW 

-qactgrp=*CALLER 
-qactgrp=actgrpname 
OPTION *GEN | *NOGEN -qgen 
-qnogen 
*DUPPROC | *NODUPPROC -qdupproc 
-qnodupproc 
*DUPVAR | *NODUPVAR -qdupvar 
-qnodupvar 
*WARN | *NOWARN -qwarn 
-qnowarn 
*RSLVREF | *UNRSLVREF -qrslvref 
-qunrslvref 
DETAIL *NONE | *BASIC | *EXTENDED | *FULL -qdetail=none 
-qdetail=basic 
-qdetail=extended 
-qdetail=full 
ALWUPD *YES | *NO -qalwupd 
-qnoalwupd 
ALWLIBUPD *YES | *NO -qalw] ibupd 
-qnoalwlibupd 
REPLACE *YES | *NO -qreplace 
-qnoreplace 
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CRTPGM and 
CRTSRVPGM 
Command Options 


Option Settings 


ixlclink Equivalents 


USRPRF 


*USER | *OWNER 


-qusrprf=user 
-qusrprf=owner 


AUT *LIBCRTAUT | *CHANGE | *USE | *ALL | *EXCLUDE | -qaut=libcrtaut 
-qaut=all 
-qaut=change 
-qaut=use 
-qaut=exclude 
TGTRLS *CURRENT | *PRV | release_ivl -qtgtr1s=current 
-qtgtrls=prv 
-qtgtr1ls=VxRxMx 
ALWRINZ *YES | *NO -galwrinz 
-qnoalwrinz 
EXPORT *SRCFILE | *ALL -qexport=srcfile 
-qgexport=all 
SRCFILE *LIBL/ | *CURLIB/ | lib_name/ -qsrcfile=[*CURLIB/ | *LIBL/ 
QSRVSRC | file_name lib_name/] QSRVSRC | file_name 
SRCMBR *SRVPGM | membername -qsrcmbr=member_name 
-qsrcmbr=*srvpgm 
STGMDL *SNGLVL | *TERASPACE -qstgmdl=snglvl 
-qstgmdl=teraspace 
IPA *YES | *NO -qipa 
-qnoipa 
IPACTLFILE *NONE | path_name -qipact]file=*none 
-qipactlfile=path_name 
IPARPLIL *YES | *NO -giparplil 
-qnoiparplil 


For more information about CRTPGM or CRTSRVPGM programs and syntax, see 


CRTIPGM (Create Program) Command Description and CRTSRVPGM (Create Service 


Program) Command Description, available on the Web from the iSeries 400 Information 


Center at: 


http://www. ibm.com/eserver/iseries/infocenter 


After selecting your operating system level, select Programming -> CL and APIs -> 
Control Language (CL) -> 0S/40@ Commands -> Alphabetical List of Commands 
from the contents menu. Alternately, use the search function to search for the terms 


CRTPGM and CRTSRVPGM. 
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Chapter 7. I/O Considerations 


This chapter provides information on: 

* Data Management Operations on Record Files 
* Data Management Operations on Stream Files 
* C Streams and File Types 

* DDS-to-C/C++ Data Type Mappings 


Data Management Operations on Record Files 


For more information about data management operations and ILE C/C++ 
functions available for record files, see the File Systems and Management section in 
the Database and File Systems category at the iSeries 400 Information Center Web 
site: 

http://publib.boulder. ibm. com/pubs/htm1/as400/infocenter.htm 


Data Management Operations on Stream Files 


To use stream files (type=record) with record I/O functions you must cast the FILE 
pointer to an RFILE pointer. 


For more information about data management operations and ILE C/C++ 
functions available for stream files, see the File Systems and Management section in 
the Database and File Systems category at the iSeries 400 Information Center Web 
site: 

http://publib.boulder. ibm. com/pubs/html /as400/infocenter.htm 


C Streams and File Types 
The following table summarizes which file types are supported as streams. 


Table 2. Processing C Stream and File Types 


Stream Database | Diskette | Tape Printer | Display | ICF DDM | Save 
TEXT Yes No No Yes No No Yes No 
BINARY: Yes No No Yes No No Yes No 
Character at 

a time 

BINARY: Yes Yes Yes Yes Yes Yes Yes Yes 
Record at a 

time 


DDS-to-C/C++ Data Type Mapping 


The following table shows DDS data types and the corresponding ILE C/C++ 
declarations that are used to map fields from externally described files to your ILE 
C/C++ program. The ILE C/C++ compiler creates fields in structure definitions 
based on the DDS data types in the externally described file. 


© Copyright IBM Corp. 1993, 2002 121 


Table 3. DDS-to-C/C++ Data Type Mappings 


Decimal 
DDS Data Type Length | Position C/C++ Declaration 
Indicator 1 0 char INxx_INyy[n]; for unused indicators xx 
through yy char INxx; for used indicator xx 
A- alphanumeric |1-32766 |none char field[n]; (where n = 1 to 32766) 
A- alphanumeric |1-32740 | none Packed struct { short len; 
variable length a char data[n]; 
VARLEN keyword } field; 
where n is the maximum length of field 
B - binary 1-4 0 short int field; 
B - binary 1-4 1-4 char field[2]; 
B - binary 5-9 0 int field; 
B - binary 5-9 1-9 char field[4]; 
H - hexadecimal 1 none char field; 
H - hexadecimal 2-32766 |none char field[n]; (where n = 2 to 32766) 
H - hexadecimal 1-32740 |none _Packed struct { short len; char data[n]; } 
variable length field; where n is the maximum length of field 
VARLEN keyword 
G - graphic 4-1000 none _Packed struct { short len; wchar_t data[n]; } 
variable length field; (where n = 4 to 1000) 
VARLEN keyword 
P - packed decimal | 1-31 0-31 decimal (n,p) where n is length and p is 
decimal position on option d 
S - zoned decimal | 1-31 0-31 char field[n]; (where n = 1 to 31) 


F - floating point 


float field; 


F - floating point 


double field; 


J - DBCS only 4-32766 |none char field[n]; (where n = 4 to 32766 and n is 
an even number) 

E - DBCS either 4 - 32766 | none char field[n]; (where n = 4 to 32766 and n is 
an even number) 

O - DBCS open 4 - 32766 | none char field[n]; (where n = 4 to 32766) 

J - DBCS only 4-32740 |none _Packed struct { short len; char data[n]; } 

variable length field; (where n = 4 to 32740 and n is an even 

VARLEN keyword number) 

E - DBCS either 4-32740 |none _Packed struct { short len; char data[n]; } 

variable length field; (where n = 4 to 32740 and n is an even 

VARLEN keyword number) 

O - DBCS open 4-32740 | none _Packed struct { short len; 

variable length char data[n]; 

VARLEN keyword } field; 
(where n = 4 to 32740) 

T - time 8 none char field[8]; 

L - date 6, 8, or none char field[n]; (where n = 6, 8 or 10) 

10 
Z - time stamp 26 none char field[26]; 


double. 


Note: [J The C declaration (float or double) is based on what is specified in the FLTPCN 
(floating-point precision) keyword in the DDS: *SINGLE (default) is float, *DOUBLE is 
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You can find more information in the DDS Reference, available in PDF and HTML 
formats from the iSeries 400 Information Center Web site at: 


http://publib.boulder.ibm.com/pubs/html/as400/infocenter.htm 
To access the DDS Reference, select the Database and File Systems category from the 


Information Center Web site, then DB2 Universal Database for AS/400, and then 
Books. 
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Appendix. Control Characters 


The following table identifies the internal hexadecimal representation of operating 
system control sequences used by the ILE C/C++ compiler and library. 


Table 4. Internal Hexadecimal Representation 


Print representation Internal representation 
NUL (null) 0x00 
SOH (start of heading) 0x01 
STX (start of text) 0x02 
ETX (end of text) 0x03 
SEL (select) 0x04 
HT (horizontal tab) 0x05 
RNL (required new line) 0x06 
DEL (delete) 0x07 
GE (graphic escape) 0x08 
SPS (superscript) 0x09 
RPT (repeat) Ox0a 
VT (vertical tab) Ox0b 
FF (form feed) Ox0c 
CR (carriage return) Ox0d 
SO (shift out) Ox0e 
SI (shift in) OxOf 
DLE (data link escape) 0x10 
DC1 (device control 1) Ox11 
DC2 (device control 2) 0x12 
DC3 (device control 3) 0x13 
RES/ENP (restore or enable presentation) 0x14. 
NL (new line) 0x15 
BS (backspace) 0x16 
POC (program-operator communication) 0x17 
CAN (cancel) 0x18 
EM (end of medium) 0x19 
UBS (unit backspace) Oxla 
CU1 (customer use 1) Ox1b 
IFS (interchange file separator) Oxic 
IGS (interchange group separator) Oxld 
IRS (interchange record separator) Oxle 
IUS/ITB (interchange unit separator or Ox1f 
intermediate transmission block) 

DS (digit select) 0x20 
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Table 4. Internal Hexadecimal Representation (continued) 


Print representation 


Internal representation 


SOS (start of significance) 


0x21 


FS (field separator) 0x22 
WUS (word underscore) 0x23 
BYP/INP (bypass or inhibit presentation) 0x24 
LF (line feed) 0x25 
ETB (end of transmission block) 0x26 
ESC (escape) 0x27 
SA (set attributes) 0x28 
SM/SW (set mode or switch) Ox2a 
CSP (control sequence prefix) Ox2b 
MFA (modify field attribute) Ox2c 
ENQ (enquiry) Ox2d 
ACK (acknowledge) Ox2e 
BEL (bell) Ox2f 
SYN (synchronous idle) 0x32 
IR (index return) 0x33 
PP (presentation position) 0x34. 
TRN 0x35 
NBS (numeric backspace) 0x36 
EOT (end of transmission) 0x37 
SBS (subscript) 0x38 
IT (indent tab) 0x39 
RFF (required form feed) Ox3a 
CU3 (customer use 3) 0x3b 
DC4 (device control 4) Ox3c 
NAK (negative acknowledge) Ox3d 
SUB (substitute) Ox3f 
(blank character) 0x40 


ILE C/C++ Compiler Reference 


Bibliography 


For additional information about topics related to ILE C/C++ programming, refer 
to the following IBM publications: 


ADTS/400: Application Development Manager User’s Guide, SCO09-2133-02, describes 
creating and managing projects defined for the Application Development 
Manager/400 feature, as well as using the program to develop applications. 


ADTS/400: Programming Development Manager, SC09-1771-00, provides 
information about using the Application Development ToolSet/400 programming 
development manager (PDM) to work with lists of libraries, objects, members, 
and user-defined options to easily do such operations as copy, delete, and 
rename. Contains activities and reference material to help the user learn PDM. 
The most commonly used operations and function keys are explained in detail 
using examples. 


ADTS for AS/400: Source Entry Utility, SCO9-2605-00, provides information about 
using the Application Development ToolSet/400 source entry utility (SEU) to 
create and edit source members. The manual explains how to start and end an 
SEU session and how to use the many features of this full-screen text editor. The 
manual contains examples to help both new and experienced users accomplish 
various editing tasks, from the simplest line commands to using pre-defined 
prompts for high-level languages and data formats. 


Application Display Programming, SC41-5715-00, provides information about: 
— Using DDS to create and maintain displays for applications; 

— Creating and working with display files on the system; 

— Creating online help information; 

— Using UIM to define panels and dialogs for an application; 

— Using panel groups, records, or documents 


Backup and Recovery, SC41-5304-05, provides information about setting up and 
managing the following: 


— Journaling, access path protection, and commitment control 
-— User auxiliary storage pools (ASPs) 
— Disk protection (device parity, mirrored, and checksum) 


Provides performance information about backup media and save/restore 
operations. Also includes advanced backup and recovery topics, such as using 
save-while-active support, saving and restoring to a different release, and 
programming tips and techniques. 


CICS Family: Application Programming Guide, SC41-5454-00, provides information 
on application programming for CICS/400®. It includes guidance and reference 
information on the CICS application programming interface and system 
programming interface commands, and gives general information about 
developing new applications and migrating existing applications from other 
CICS platforms. 

ILE C/C++ for AS/400 MI Library Reference, SCO09-2418-00, provides information on 
Machine Interface instructions available in the C for AS/400 compiler that 
provide system-level programming capabilities. 

CL Programming, SC41-5721-04, provides a wide-ranging discussion of AS/400 
programming topics including a general discussion on objects and libraries, CL 
programming, controlling flow and communicating between programs, working 


© Copyright IBM Corp. 1993, 2002 127 


128 


with objects in CL programs, and creating CL programs. Other topics include 
predefined and impromptu messages and message handling, defining and 
creating user-defined commands and menus, application testing, including 
debug mode, breakpoints, traces, and display functions. 


Communications Management, SC41-5406-02, provides information about work 
management in a communications environment, communications status, tracing 
and diagnosing communications problems, error handling and recovery, 
performance, and specific line speed and subsystem storage information. 


Experience RPG IV Multimedia Tutorial, SK2T-2700, is an interactive self-study 
program explaining the differences between RPG ITI and RPG IV and how to 
work within the new ILE environment. An accompanying workbook provides 
additional exercises and doubles as a reference upon completion of the tutorial. 
ILE RPG code examples are shipped with the tutorial and run directly on the 
AS/400. 


GDDM Programming Guide, SC41-0536-00, provides information about using 
OS/400 graphical data display manager (GDDM”“) to write graphics application 
programs. Includes many example programs and information to help users 
understand how the product fits into data processing systems. 


GDDM Reference, SC41-3718-00, provides information about using OS/400 
graphical data display manager (GDDM) to write graphics application programs. 
This manual provides detailed descriptions of all graphics routines available in 
GDDM. Also provides information about high-level language interfaces to 
GDDM. 


ICF Programming, SC41-5442-00, provides information needed to write 
application programs that use AS/400 communications and the OS/400 
intersystem communications function (OS/400-ICF). Also contains information 
on data description specifications (DDS) keywords, system-supplied formats, 
return codes, file transfer support, and program examples. 


IDDU Use, SC41-5704-00, describes how to use the AS/400 interactive data 
definition utility (IDDU) to describe data dictionaries, files, and records to the 
system. Includes: 


— An introduction to computer file and data definition concepts 


— An introduction to the use of IDDU to describe the data used in queries and 
documents 


— Representative tasks related to creating, maintaining, and using data 
dictionaries, files, record formats, and fields 


— Advanced information about using IDDU to work with files created on other 
systems and information about error recovery and problem prevention. 


ILE C/C++ Programmer’s Guide, SC09-2712-02, provides programming information 
about the ILE C/C++ compiler. It includes programming considerations for 
interlanguage program and procedure calls, locales, handling exceptions, 
database, and device files. Examples are provided and performance tips for 
programming are also discussed. 


ILE C/C++ Language Reference, SC09-4815-00, provides reference information 
about the ILE C/C++ compiler, including elements of the language, statements, 
and preprocessor directives. Examples are provided and considerations for 
programming are also discussed. 


ILE C for AS/400 Run-Time Library Reference, SC41-5607-00, provides reference 
information about C for AS/400 library functions, including Standard C library 
functions and C for AS/400 library extensions. Examples are provided and 
considerations for programming are also discussed. 


ILE C/C++ Compiler Reference 


ILE COBOL Programmer's Guide, SC09-2540-02, provides information about how 
to write, compile, bind, run, debug, and maintain ILE COBOL programs on the 
AS/400 system. It provides programming information on how to call other ILE 
COBOL and non-ILE COBOL programs, share data with other programs, use 
pointers, and handle exceptions. It also describes how to perform input/output 
operations on externally attached devices, database files, display files, and ICF 
files. 


ILE COBOL Reference, SCO09-2539-02, provides a description of the ILE COBOL 
programming language. It provides information on the structure of the ILE 
COBOL programming language and the structure of an ILE COBOL source 
program. It also provides a description of all Identification Division paragraphs, 
Environment Division clauses, Data Division clauses, Procedure Division 
statements, and Compiler-Directing statements. 


ILE COBOL Reference Summary, SX09-1317-02, provides quick reference 
information on the structure of the ILE COBOL programming language and the 
structure of an ILE COBOL source program. It also provides syntax diagrams of 
all Identification Division paragraphs, Environment Division clauses, Data 
Division clauses, Procedure Division statements, and Compiler-Directing 
statements. 


ILE Concepts, SC41-5606-05, explains concepts and terminology pertaining to the 
Integrated Language Environment architecture of the OS/400 licensed program. 
Topics covered include creating modules, binding, running programs, debugging 
programs, and handling exceptions. 


ILE RPG Programmer's Guide, SC09-2507-03, provides information about the ILE 
RPG programming language, which is an implementation of the RPG IV 
language in the Integrated Language Environment (ILE) on the AS/400 system. 
It includes information on creating and running programs, with considerations 
for procedure calls and interlanguage programming. The guide also covers 
debugging and exception handling and explains how to use AS/400 files and 
devices in RPG programs. Appendixes include information on migration to RPG 
IV and sample compiler listings. It is intended for people with a basic 
understanding of data processing concepts and of the RPG language. 


ILE RPG Reference, SC09-2508-03, provides information about the ILE RPG 
programming language. This manual describes, position by position and 
keyword by keyword, the valid entries for all RPG IV specifications, and 
provides a detailed description of all the operation codes and built-in functions. 
This manual also contains information on the RPG logic cycle, arrays and tables, 
editing functions, and indicators. 


ILE RPG Reference Summary, SX09-1315-02, provides information about the RPG 
III and RPG IV programming language. This manual contains tables and lists for 
all specifications and operations in both languages. A key is provided to map 
RPG III specifications and operations to RPG IV specifications and operations. 


Local Device Configuration, SC41-5121-00, provides information about configuring 
local devices on the AS/400 system. This includes information on how to 
configure the following: 


— Local work station controllers (including twinaxial controllers) 
— Tape controllers 
-— Locally attached devices (including twinaxial devices) 


Machine Interface Functional Reference, SC41-5810-00, describes the machine 
interface instruction set. Describes the functions that can be performed by each 
instruction and also the necessary information to code each instruction. 


Printer Device Programming, SC41-5713-04, provides information to help you 
understand and control printing. Provides specific information on printing 


Bibliography 129 


130 


elements and concepts of the AS/400 system, printer file and print spooling 
support for printing operations, and printer connectivity. Includes considerations 
for using personal computers, other printing functions such as Business Graphics 
Utility (BGU), advanced function printing (AFP), and examples of working with 
the AS/400 system printing elements such as how to move spooled output files 
from one output queue to a different output queue. Also includes an appendix 
of control language (CL) commands used to manage printing workload. Fonts 
available for use with the AS/400 system are also provided. Font substitution 
tables provide a cross-reference of substituted fonts if attached printers do not 
support application-specified fonts. 


REXX/400 Programmer's Guide, SC41-5728-00, provides a wide-ranging discussion 
of programming with REXX on the AS/400 system. Its primary purpose is to 
provide useful programming information and examples to those who are new to 
Procedures Language 400/REXX and to provide those who have used REXX in 
other computing environments with information about the Procedures Language 
400/REXX implementation. 


ILE RPG Programmer's Guide, SC09-2507-03, provides information needed to 
design, code, compile, and test RPG programs on the AS/400 system. The 
manual provides information on data structures, data formats, file processing, 
multiple file processing, the automatic report function, RPG command 
statements, testing and debugging functions, application design techniques, 
problem analysis, and compiler service information. The differences between the 
RPG for AS/400 compiler, the System/38® environment RPG III compiler, and 
the System/36°-compatible RPG II compiler are also discussed. 


iSeries Security Reference, SC41-5302-04, tells how system security support can be 
used to protect the system and the data from being used by people who do not 
have the proper authorization, protect the data from intentional or unintentional 
damage or destruction, keep security information up-to-date, and set up security 
on the system. 


Local Device Configuration, SC41-5121-00, provides step-by-step procedures for 
initial installation, installing licensed programs, program temporary fixes (PTFs), 
and secondary languages from IBM. This manual is also for users who already 
have an AS/400 system with an installed release and want to install a new 
release. 


System API Programming, SC41-5800-00, provides information for the experienced 
application and system programmers who want to use the OS/400 application 
programming interfaces (APIs). Provides getting started and examples to help 
the programmer use APIs. 


System Operation, SC41-4203-00, provides information about handling messages, 
working with jobs and printer output, devices communications, working with 
support functions, cleaning up your system, and so on. 


Tape and Diskette Device Programming, SC41-5716-01, provides information to help 
users develop and support programs that use tape and diskette drives for I/O. 
Includes information on device files and descriptions for tape and diskette 
devices. 


ILE C/C++ Compiler Reference 


Notices 
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IBM may not offer the products, services, or features discussed in this document in 
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products and services currently available in your area. 


Any reference to an IBM product, program, or service is not intended to state or 
imply that only IBM product, program, or service may be used. Any functionally 
equivalent product, program, or service that does not infringe any of IBM’s 
intellectual property rights may be used instead. However, it is the user’s 
responsibility to evaluate and verify the operation of any non-IBM product, 
program, or service. 


IBM may have patents or pending patent applications covering subject matter in 
this document. The furnishing of this document does not give you any license to 
these patents. You can send license inquiries, in writing, to: 


Director of Licensing, 

Intellectual Property & Licensing 
International Business Machines Corporation, 
North Castle Drive, MD - NC119 

Armonk, New York 10504-1785, 

U.S.A. 


The following paragraph does not apply to the United Kingdom or any other 
country where such provisions are inconsistent with local law: 
INTERNATIONAL BUSINESS MACHINES CORPORATION PROVIDES THIS 
PUBLICATION “AS IS” WITHOUT WARRANTY OF ANY KIND, EITHER 
EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED 
WARRANTIES OF NON-INFRINGEMENT, MERCHANTABILITY OR FITNESS 
FOR A PARTICULAR PURPOSE. Some states do not allow disclaimer of express or 
implied warranties in certain transactions, therefore, this statement may not apply 
to you. 


This information could include technical inaccuracies or typographical errors. 
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incorporated in new editions of the publication. IBM may make improvements 
and/or changes in the product(s) and/or the program(s) described in this 
publication at any time without notice. 


Any references in this information to non-IBM Web sites are provided for 
convenience only and do not in any manner serve as an endorsement of those Web 
sites. The materials at those Web sites are not part of the materials for this IBM 
product and use of those Web sites is at your own risk. 


Licensees of this program who wish to have information about it for the purpose 
of enabling: (i) the exchange of information between independent created programs 
and other programs (including this one) and (ii) the mutual use of the information 
which has been exchanged, should contact: 


IBM Canada Ltd. 
Department 071 
1150 Eglinton Avenue East 
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Toronto, Ontario M3C 1H7 
Canada 


Such information may be available, subject to appropriate terms and conditions, 
including in some cases payment of a fee. 


The licensed program described in this information and all licensed material 
available for it are provided by IBM under terms of the IBM Customer Agreement, 
IBM International Program License Agreement, or any equivalent agreement 
between us. 
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operations. To illustrate them as completely as possible, the examples include the 
names of individuals, companies, brands, and products. All of these names are 
fictitious and any similarity to the names and addresses used by an actual business 
enterprise is entirely coincidental. 


Programming Interface Information 
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Environment C/C++ compiler and documents general-use programming interfaces 
and associated guidance information provided by the Integrated Language 
Environment C/C++ compiler. 


Trademarks and Service Marks 
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H 


hashome pragma 43 


if preprocessor directive 12 
ifdef preprocessor directive 13 
ifndef preprocessor directive 13 
implementation pragma 44 
import pragma 44 

include preprocessor directive 8 
indentation of code 2 

info pragma 45 
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inline pragma 46 
ishome pragma 46 
isolated_call pragma 47 
ixlc 
command 109 
command options 110 
ixlclink 117 
ixlclink options 118 


L 


line preprocessor directive 15 
linkage pragma 48 


macro 
definition 2,3 
invocation 3 

macro preprocessor directives 2 

macros 17 
_ANSI_ 18 
__ASYNC_SIG__ 18 
__CHAR_SIGNED__ 18 
__CHAR_UNSIGNED__ 19 
__COMPAT__ 19 
_cplusplus 17 
__EXTENDED__ 19 
__FUNCTION__ 19 
__HHW_AS400__ 19 
__HOS_OS400__ 19 


_IBMCPP__ 19 
_IFS_IO_ 19 

__IFS64_IO__ 19 
__ILEC400__ 19 


__ILEC400_TGTVRM__ 19 
__LLP64_IFC_ 19 
__LONG_LONG__ 19 
_OS400__ 20 
OS400_TGTVRM 20 
POSIX_LOCALE 20 
__RTTILDYNAMIC_CAST__ 
__SRCSTMF__ 20 
__TERASPACE 20 
__THW_AS400__ 20 
__TIMESTAMP__ 20 
__TOS_OS400__ 20 
_UCS2__ 21 
__wcehar_t 21 
_LARGE_FILE_API 19 
_LARGE_FILES 19 
DATE 17 
FILE 17 
LINE 17 
STDC 17 
TIME 17 

map pragma 49 

mapinc pragma 49 

margins pragma 52 


N 


namemangling pragma 53 
naming files 8 

noargv0 pragma 53 
noinline pragma 54 
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nomargins pragma 54 
nosequence pragma 55 
nosigtrunc pragma 55 

null preprocessor directive 16 
number sign (#) 2 


preprocessor directive character 


preprocessor operator 6 


O 


object_model pragma 55 
object-like macro 2 


operational descriptor pragma 32 


operator 6 
operator 1 7 
operators 
preprocessor 
# 6 
Ht 7 


Pp 


pack pragma 56 
page pragma 61 
pagesize pragma 61 
pointer pragma 62 
pound sign (#) 2 


preprocessor directive character 


preprocessor operator 6 
pragma 24 
argopt 24 
argument 26 
cancel_handler 27 
chars 28 
checkout 28 
comment 29 
convert 30 
datamodel 31 
define 32 
disable_handler 34 
disjoint 34 
entry 35 
enum 36 
enumsize 39 
exception_handler 40 
hashome 43 
implementation 44 
import 44 
info 45 
inline 46 
ishome 46 
isolated_call 47 
linkage 48 
map 49 
mapinc 49 
margins 52 
namemangling 53 
noargv0 53 
noinline 54 
nomargins 54 
nosequence 55 
nosigtrunc 55 
object_model 55 
operational descriptor 32 
pack 56 
page 61 


2 


2 


pragma (continued) 

pagesize 61 

pointer 62 

priority 63 

sequence 64 

skip 64 

strings 65 

work 65 
predefined macros 17 
preprcocessor directive 1 

tokens 1 

white space 1 
preprcocessor directives 1 
preprocessor directive 2 

conditional compilation 11 

define 2 

elif 12 

else 14 

endif 14 

error 8 

if 12 

ifdef 13 

ifndef 13 

include 8 

line 15 

null 16 
preprocessor operator 

# 6 

HH 7 
priority pragma 63 


Q 


Qshell 109 


S 


sequence pragma 64 

single level storage model 96 
skip pragma 64 

space character 2 


splice preprocessor directive ## 7 


stream type 121 
strings pragma 65 
structures 
packing 
using #pragma pack 56 


7 


templates 
pragma define 32 
pragma implementation 44 
teraspace 96 
tokens 1 


U 


undef preprocessor directive 5 
unions 
packing 
using #pragma pack 56 


W 


white space 1, 2,6 
work pragma 65 


Index 135 


136 ILE C/C++ Compiler Reference 


Program Number: 5722—WDS 


SC09-4816-01 


